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

Technologia ASP (Active Server Pages), zastosowana w tym narzędziu, jest bardzo prosta. Polega na przeplataniu języka HTML, opisującego stronę, z fragmentami w języku VBScript (to uproszczona wersja Visual Basica), w którym opisana jest dynamika aplikacji internetowej. W momencie, gdy przeglądarka na zdalnym komputerze zażąda strony ASP, serwer wykona kod VBScript, znajdujący się na stronie, zwracając z powrotem przetworzony HTML, wzbogacony np. w dynamiczne informacje. Osoby, które stosowały bardzo popularną na Linuxie technologię PHP, z pewnością szybko znajdą analogię do ASP.

Narzędzie Visual InterDev posiada też prosty edytor wizualny, który umożliwi utworzenie zrębów strony nawet bez dokładnej znajomości języka HTML. Stopień trudności fragmentów HTML-a, cytowanych w tym artykule, nie będzie wychodzić poza rozwiązanie możliwe do osiągnięcia w wizualnym edytorze.

Architektura

Zasadnicza trudność wykonania tak pomyślanego rozwiązania polega na pewnych istotnych cechach protokołu HTTP. Protokół ten jest bezstanowy (stateless), a więc nie można przechować między wywołaniami stanu obiektu klasy "CKredyt" z komponentu zdefiniowanego w pierwszym odcinku tego artykułu.

Jeżeli nie chcemy stosować bazy danych (trzeba by przebudować już istniejący komponent), najprostszym wyjściem jest przekazywanie całej informacji z wywołania na wywołanie. Innymi słowy oznacza to, że zarówno informacja o kredycie, jak i cały plan spłat będą każdorazowo przechowywane na stronie i wysyłane do serwera. Ten zaś za każdym razem od nowa stworzy obiekt klasy "CKredyt", doda do niego WSZYSTKIE spłaty i udostępni możliwość dodania kolejnej raty.

Zaletą takiego rozwiązania jest prostota z punktu widzenia architektury aplikacji i zamknięcie funkcjonalności w ramach istniejącej koncepcji programistycznej (czyli gotowego komponentu COM). Takie rozwiązanie ogranicza także zużywaną pamięć, bo komponenty aplikacji powoływane są tylko na czas generowania strony, a po jej przesłaniu do aplikacji po prostu znikają. Daje to lepszą skalowalność aplikacji, w szczególności na serwerach, które będą musiały obsługiwać wiele wywołań jednocześnie. Wadą takiego rozwiązania jest oczywiście prędkość, bo przy kredycie, który spłaca się w wielu ratach, budowa całej struktury opisanej w artykule od podstaw to zwykłe marnotrawstwo mocy obliczeniowej procesora.

Dialog z użytkownikiem

Żelazna zasada tworzenia oprogramowania mówi: "Zanim zaczniesz pisać program, zastanów się co chcesz pisać". Skoro zdecydowaliśmy o architekturze i technologii, czas zaprojektować dialog z użytkownikiem. Pamiętajmy, że z serwisu będzie korzystać Kowalski, operujący dość sprawnie myszką, ale z pewnością nie rozumiejący takich pojęć, jak URL, wywołanie, stan aplikacji itd. W szczególności musimy zadbać, aby nasza aplikacja internetowa

  • prezentowała informacje w sposób prosty i czytelny

  • dostarczała kompletnych wyjaśnień

  • chroniła przed popełnieniem błędu

  • umożliwiała cofnięcie wykonanej operacji

  • "wyprzedzała" życzenia użytkownika, pomagając mu osiągnąć efekt minimalną liczbą kroków

    Zastanówmy się po kolei jak osiągnąć każdy z tych celów. Do prostego i czytelnego prezentowania informacji tekstowej możemy użyć odpowiedniej wielkości czcionki, jej kroju i koloru. Informacja "podstawowa" - czyli np. objaśnienie, lista już zarejestrowanych rat - powinna być pisana zwykłym pismem, ciemnym na jasnym tle. Informacje kluczowe, a więc poszukiwana wielkość Rzeczywistej Rocznej Stopy Procentowej i ewentualne informacje o błędach, powinny być zaznaczone dużymi literami, kontrastowym kolorem. Strona powinna także wyraźnie oddzielać część informacyjną od części aktywnej (czyli miejsca, gdzie można będzie coś wpisać), aby użytkownik nie czuł się zagubiony. Oczywiście, na każdej stronie powinny znajdować się kompletne wiadomości - do czego ta część serwisu służy i co oznaczają określone informacje.


  • TOP 200