Od pomysłu do serwisu - część druga

Przyjrzyjmy się teraz temu formularzowi - język HTML nie jest tak straszny, jak go czasem malują. Formularz ten posiada jedno pole tekstowe o nazwie KwotaKredytu. Proszę zwrócić uwagę na kod zawarty między znakami <% oraz %> - znajduje się tam wywołanie funkcji MiejsceNaDate z trzema parametrami. Funkcja ta powoła trzy rozwijane listy, wykorzystując tag <OPTION> języka HTML. Listy te będą zawierać dni, miesiące i lata. Zostaną one nazwane tak jak parametry funkcji MiejsceNaDate, czyli DzienUdz, MiesUdz, RokUdz. Wartości wybrane przez użytkownika zostaną przekazane pod takimi właśnie nazwami do strony kredyt.asp, wskazanej w tagu <FORM>. Innymi słowy, formularz wywoła stronę kredyt.asp z parametrami zawierającymi wybraną przez użytkownika kwotę kredytu oraz dzień, miesiąc i rok jego udzielenia.

Komentarza wymaga słowo post w tym samym tagu. Generalnie istnieją dwie metody przekazywania danych w formularzach na stronach internetowych: get oraz post. Patrząc technicznie, różnica między nimi jest taka, że dane przekazane przez get zostaną umieszczone w linii wywołania (URL-u) strony, a dane przekazane przez post nie. Jednak nie techniczna różnica jest interesująca, a praktyczna. W przypadku użycia get, dane o kwocie kredytu i jego dacie będą stanowiły element URL-a strony kredyt.asp. Można by więc wtedy wykonać w przeglądarce zakładkę na takim adresie wzbogaconym w parametry i wykorzystywać tę stronę później. Łatwo byłoby też zrobić link do strony opisującej kredyt na zadaną kwotę i udzielony w konkretnym dniu, umieszczając obok adresu strony odpowiednie dane takiego kredytu. Na przykład kredyt na 1000 zł, udzielony 1 stycznia 2000 r., opisywałby URL: !http://adres.serwera.pl/kredyt.asp?KwotaKredytu=1000&DzienUdz=1&MiesUdz =1&RokUdz=2000

Stosowanie get ma jednak dwie wady. Pierwsza, to ograniczenie długości URL-a. Wiele przeglądarek przyjmuje ograniczoną liczbę znaków (np. 1024), a ponadto epidemia robaków Nimda i Code Red sprawiła, że serwery podejrzliwie patrzą na długie wywołania. Drugą wadą takiego rozwiązania byłoby umieszczenie informacji o kredytach klientów korzystających z naszego serwisu w logach serwera. Szanując prywatność naszych klientów i ich bezpieczeństwo, w konstrukcji całego serwisu będziemy posługiwać się metodą post.

Wykonanie - strona wpłat

Jak pamiętamy z projektu architektury naszej aplikacji, strona kredyt.asp ma dwie funkcje: wyświetlanie już zarejestrowanych rat i możliwość dodania nowej daty. Zajmijmy się na razie tą drugą opcją, gdyż jest ona prostsza. W gruncie rzeczy nie ma żadnej różnicy między poprzednio opisanym formularzem HTML, służącym do określania kredytu, a nowym formularzem, służącym do nowej wpłaty. W jednym i drugim miejscu podajemy datę i kwotę. Pamiętajmy tylko o wymaganiach użytkowych: domyślna kwota nowej wpłaty powinna być identyczna z poprzednią, a data nowej wpłaty powinna być o miesiąc późniejsza niż poprzednio zarejestrowana wpłata.

<FORM method=post action=kredyt.asp>

...

<input id=txtKwotaNow name=KwotaNow value=<%=sKwotaNowejWplaty%>>

<%

MiejsceNaDate "DzienNow", "MiesNow", "RokNow", dPrzewidywanaDataWplaty

%>

<INPUT id=cmdWplata type=submit value="Dodaj wpłatę">

</FORM>

Podobnie jak w poprzednim formularzu, przesyłamy zmienne do strony kredyt.asp - czyli do tej samej, na której aktualnie jesteśmy. Stosowana jest również metoda post. Jak jednak widać, użyto dwóch zmiennych: dPrzewidywanaDataSplaty zawiera datę o miesiąc późniejszą od ostatniej (implementację funkcji wyliczającej taką datę pomińmy, można ją zobaczyć w źródłach aplikacji udostępnionych na WWW). Interesujący jest także zapis <%=sKwotaNowejWplaty%>. Internet Information Server w czasie przetwarzania strony ASP, po napotkaniu znaków <%= w to miejsce na stronie wstawi wartość podanej zmiennej (sKwotaNowejWplaty, w naszym przypadku). Oczywiście, przy rejestrowaniu pierwszej wpłaty ta wartość będzie pusta. Uważny czytelnik z pewnością zauważył trzy kropeczki w drugiej linii - tą częścią zajmiemy się później.


TOP 200