Tworzenie aplikacji web based w Pascalu

Cel, założenia

Stworzenie biblioteki umożliwiającej przeniesienie istniejących aplikacji do sfery web-based, czyli umożliwienie tworzenia aplikacji internetowych. Dodatkowymi wymaganiami były: maksymalne wykorzystanie istniejącego kodu, oparcie o standardy (w3c.org), minimalizacja różnic w wyglądzie i obsłudze w stosunku do tradycyjnych aplikacji. Nie do pogardzenia były by możliwość wykorzystania systemu operacyjnego Linux.

Wprowadzenie

Tworzenie aplikacji internetowych w dużej mierze oparte jest o języki skryptowe. Gwałtowny ich rozwój ukazał bogactwo form i możliwości, w dłuższym okresie czasu ujawniły się słabości tychże rozwiązań. O tyle są one istotne, że występują na poziomie podstawowym, fundamentalnym co powoduje, że ominięcie czy zignorowanie występujących problemów jest trudne bądź niemożliwe.

Co więcej, problemy te narastają wraz ze wzrostem złożoności tworzonych programów, co nie jest dobrym prognostykiem. Podstawowe problemy to szybkość, słabość języka, przeplatanie struktur programu z kodem HTML, niestabilny rozwój (brak kompatybilności wstecz). Dla wielu związanych z rynkiem aplikacji desktopowych ideałem byłoby jedno narzędzie umożliwiające równoległe tźąworzenie aplikacji na wszystkie platformy, tzn. operujące na tym samum kodzie źródłowym.

Delphi nie jest świadomym, obiektywnym i niezależnym wyborem narzędzia. Jest wynikiem istniejących uwarunkowań, zastanej sytuacji. Decyzja została podjęta na zasadzie braku możliwości udowodnienia tezy o całkowitej nieprzydatności tego narzędzia do tworzenia aplikacji internetowych.

Drogę do celu wyznaczyło szereg doświadczeń i przykładów, które łącznie z dokonanymi pracami implementacyjnymi pozwoliły na osiągnięcie sukcesu w realizacji ww celu. I tak jako wzór aplikacji wieloplatformowych można przedstawić FPC. Po drugie implementacja bibliotek wizualnych zrealizowana w projekcie Lazarus jest przykładem jak można całkowicie różne interfejsy graficzne opakować w jedno spójne API. Co więcej, jest to dowód że takim najlepszym API jest to zawarte w VCL Delphi. Oczywiście nic by się nie udało gdyby nie istniały biblioteki komunikacji internetowej Indy i Synapse. Wszystko rozpoczęło się od przykładu serwera Elize z Indy, choć ta biblioteka nie jest już używana.

Kolejnym krokiem była analiza bibliotek komponentów utworzonych w Javascript i wykorzystujących AJAX , takich jak Ext Js, Dojo itd. Okazało się, że wystarczy że aplikacja serwerowa wygeneruje tylko stosunkowo niewielkiej długości łańcuchy, a całą resztę dokona przeglądarka. Pod pewnymi względami stało się to prostsze niż rysowanie po ekranie w Windows. Ostatecznym dowodem była biblioteka Wt (do tworzenia aplikacji webowych w C++). Ona unaoczniła, że przedstawiony zamiar jest możliwy do realizacji.

Architektura rozwiązania

serwer HTTP wbudowany w aplikację (biblioteka Synapse),
obsługa sesji (każda sesja to jakby jedna instancja aplikacji dla jednego użytkownika),
AJAX: każde działanie przekazywane do serwera, który każdorazowo generuje i przesyła zmiany do przeglądarki,
praca wielowątkowa aplikacji:
- wątek główny,
  - wątek przyjmowania zapytań i generowania odpowiedzi: dla każdego zapytania tworzony odrębny wątek,
  - wątek aplikacji: dla każdego użytkownika odrębny,
  komunikacja pomiędzy wątkami zapytań a aplikacyjnym odbywa się przy pomocy kolejki FIFO (implementacja waitfree),
- wątki pomocnicze: wątek aplikacyjny niektóre obliczenia dokonuje w trybie wielowątkowym i ta możliwość została zachowana,
maksymalna zgodność z architekturą i API bibliotek VCL:
kolejki komunikatów analogicznej to tej z Windows (wndProc),
lista okien (Forms),
kontrolki (comctrls,stdctrls,menu,grid)
okna modalnych (okna dialogowe) w 100% zgodnych z Delphi (blokada przyjmowania zdarzeń z innych okien, zatrzymanie programu) (Dialogs).

Zawartość plików:

ajax1.js - podstawowa obsługa wywołań XMLHttpRequest, komunikacja serwer-przeglądarka
xlhttp - implementacja serwera HTTP, z obsługą sesji
hthttp - implementacja serwera aplikacyjnego, komunikacja socket - instancja aplikacji
xlapp - korzeń obiektów HTML
xlcontrol, xlgraphics, xlmenu, xlform

Komunikacja z przeglądarką

Przeglądarka pod pewnymi względami jest podobna w swej strukturze do środowiska windows. Występują w niej takie same kontrolki jak przykładowo input (tEdit), button, checkbox. Bardzo podobna jest również obsługa, w tym możliwość oprogramowania takich samych zdarzeń (onClick, onChange, onMouseMove). Natomiast istnieje szereg różnic i to na różnych poziomach, których niwelacja jest konieczna aby umożliwić efektywne tworzenie aplikacji internetowych w sposób analogiczny to rozwiązań windowsowych.
Należy tu wymienić:

automatyczny rendering wraz z brakiem możliwości rysowania piksel po pikselu, co znacznie utrudnia tworzenie zarówno bardziej skomplikowanych kontrolek jak również wprowadza utrudnienia przy rozmieszczeniu komponentów na ekranie
płaskie pojedyncze okno, w odróżnieniu od "okienkowego" windowsa,
duża rozpiętość rozdzielczości ekranu (palmtopy),
praca z wieloma użytkownikami jednocześnie, bezpołączeniowy protokół (w Windows przy jednym komputerze jest zazwyczaj jeden użytkownik),
możliwość wielokrotnego otrzymania tego samego zapytania,
utrudniona komunikacja zwrotna (brak odczytu która kontrolka "ma focus"),
większa zawodność łącza (niektóre polecenia mogą zostać zignorowane, bo nie "doszły" do przeglądarki.

Natomiast z pomocą przychodzą narzędzia, które umożliwiają dokonania wszelkich koniecznych obejść :

XMLHttpRequest: najsłynniejsze, podstawa wszelkich aplikacji RIA,
DOM: Document Object Model,
wielowarstwowy rendering.

Stosowane technologie

100% Ajax

Całość odbywa się wyłącznie poprzez wywołania asynchroniczne, brak wywołań powodujących przeładowanie strony, dzięki czemu aplikacja staje się odporna na standardowe operacje przeglądarkowe typu reload czy back, które to mogą powodować znaczne niedogodności w użytkowaniu aplikacji.

Cookie

Do zapamiętania i identyfikowania sesji - zrezygnowano całkowicie z jakiegokolwiek zapamiętywania stanów pośrednich w przeglądarce. Wszystkie działania użytkownika (kliknięcie, naciśnięcie klawisza, ruch myszką) powodujące taką zmianę transmitowane są do serwera, który dokonuje odpowiednich operacji i generuje zmiany na stronie. Jedynym wyjątkiem są naturalne zachowania niektórych komponentów np. menu.

JavaScript

Zapewnienie komunikacji pomiędzy serwerem a użytkownikiem: realizuje funkcje wymiany strony, wymiany pojedynczych elementów strony, wyświetlenie okien dialogowych, obsługa menu i wyboru daty.

Html

implementacja formularzy przy pomocy tabelki: skalowanie, wymiarowanie, duża zgodność pomiędzy przeglądarkami,
pominięcie elementu href (linki) ze względu na zatrzymywanie się tabulatora na tych elementach,
obsługa onClick, onChange, onKeyUp,
adres strony = adres obiektu w pamięci serwera: unikalność, jednoznaczność, automatyczne mapowanie.

CSS

odpowiada za wizualizacje: wymiary, kolory, czcionki, bitmapy,
odrębny CSS na palmtopy, GSM, komputery stacjonarne.

Optymalizacja transferu

prawidłowe ustawienia cache przeglądarki
statyczne obrazki, skrypty i css
zmienione kontrolki
zmienione wartości kontrolek
reload całości okna
możliwość pakowania zip
czas generowania odpowiedzi 0.2-15.0 ms
czas podawany w Firebug dla sieci lokalnej 2..30 ms
wielkość ramki 2..50 kB

Tworzenie aplikacji web based

Program klasy "hello world"

Wykorzystanie elementów standardowych:

Tcontrol
tEdit
Tbutton
tFont
tBrush
tForm

Styl programowania:

Formatki zapisywane są w postaci kodu (pure pascal), notacja wywodzi się z biblioteki Turbo Power.
Unikanie "pisania w" HTML .
Kompilacja warunkowa.
Zmienne globalne - nowe spojrzenie.

Rozszerzenia komponentów

tFieldBox, tFieldDBL,
okno dialogowe,
wizualizacja progresji,
TpageControl,
tMenu,
Grid: Komunikacja, buforowanie.

Do zrobienia

obsługa klawiatury,
komponent virtualtreeview,
wykorzystanie SVG (bardziej wyrafinowane kontrolki),
implementacja jako FastCGI,
przekazanie biblioteki do środowiska OpenSource.

Pominięte zagadnienia

raportowanie : wykorzystanie przeglądarki PDF,
drukarki i kasy fiskalne: (potencjalnie ActiveX),
komunikacja z pakietem biurowym.

Biblioteka

Został przygotowany "minimalistyczny" zestaw plików, które można samodzielnie skompilować i uzyskać demonstracyjną wersję programu. źródła do pobrania z:
http://www.emadar.com/fpc/xwebdemo.zip
Biblioteka powinna się kompilować pod Delphi i FPC. Potrzebne jest jedynie pobranie Synapse.
Główny plik to htunittest.pas
zawiera proste okno z polami typu input i buttony, po naciśnięciu których mamy typowe okno komunikatu.

Pomimo że na pierwszy rzut oka jest to całkowicie nowy sposób tworzenia interfejsu, w całości jest on tworzony dynamicznie poprzez sekwencje wywołań procedur typu:
te:=AddSimpleStringField('login',3,8,'X',3,22,14,10,1,fLogin);
to po głębszej analizie można zauważyć, że wnętrze jest bardzo podobne do bibliotek VCL (zgodność API na poziomie nazewnictwa i struktury) a to co potrzebne to rodzaj pośrednika pomiędzy własnym a tym stosowanym w bibliotece.

Wnioski

Zastosowanie

Biblioteka stosowana jest w programie, który właśnie przechodzi pierwsze wdrożenia produkcyjne. Działa dobrze i stabilnie. Największy problem to przekonanie użytkowników do nowego interfejsu. Przyzwyczajenia z aplikacji desktopowych są niezliczone. Ale wszystko jest na jak najlepszej drodze.

Przeznaczenie

Jeden kod na wiele platform (vide FPC): desktop Windows - web based. Serwer obecnie Linux i Windows, potencjalnie inne, jako przeglądarka IE, Firefox, Safari, Opera również w wersjach na palmtopy.
0 kodu HTML
0 różnic wersja mobilna - desktopowa
0 zależności od środowiska i dystrybucji
Całość programu zawarta w pojedynczym EXE o stosunkowo niewielkiej objętości i niewielkiego zapotrzebowania na pozostałe zasoby, co wskazuje na potencjalne zastosowanie w systemach wbudowanych.