Trochę inne programowanie…

Za namową Forgera postanowiłem przyjrzeć się framework’owi ExtJS. Generalnie rzecz biorąc jest to środowisko programistyczne JavaScript, które pomaga programistom tworzyć dynamiczne aplikacje WWW. Od typowego połączenia XHTML + PHP różni się ono tym, że za prezentację danych odpowiadają okna, panele i inne kontrolki generowane przez JS. PHP (czy inny język/framework działający po stronie serwera) w zasadzie służy tylko do komunikacji z bazą danych.

Spędziłem dwa dni wprowadzając w życie pomysł, który w czwartek podrzucił mi mój kolega z pracy. Chodziło o to, żeby rozszerzyć funkcjonalność widget’u “żółte karteczki” o możliwość wysyłania notatek innym użytkownikom. Postanowiłem wykorzystać do tego kombinację Dashboard’a (Makowego silnika widget’ów), ExtJS (jako warstwy prezentacji danych) i PHP (do obsługi operacji bazodanowych). Prawie mi się udało. W przeglądarkach aplikacja działa świetnie. Niestety pokonał mnie Dashboard, a dokładniej środowisko w jakim żyją widget’y. Obszedłem wiele ograniczeń i problemów - znikające przyciski, których stan zależał od poprawności formularza, brak obsługi ciasteczek (zastąpiłem je wbudowanymi w Dashboard preferencjami widget’ów) oraz okienka dialogowe zasłaniane przez inne okna (czyli motanina z z-index’em). Ostatnim problemem, który mnie niestety pokonał, są znikające przyciski w oknach dialogowych. Jeśli user kliknie OK w jednym okienku to w drugim (np. proszącym o potwierdzenie usuwania jakiegoś wpisu) już się ten przycisk nie pojawi. Winą obarczam haki, które Apple zaaplikowało WebKit’owi napędzającemu Dashboard. Testowo podmieniłem biblioteki tak, żeby Dash korzystał z tego samego WebKit’a co Safari i moja aplikacja działała poprawnie, ale niestety inne widget’y sie sypały w mniej lub bardziej spektakularny sposób. Na tą chwilę złożyłem broń. Mam co prawda jeden pomysł (własna klasa okienka dialogowego), ale jestem już zbyt zmęczony na walkę z kodem…

Z żalem jednak muszę coś stwierdzić. Podejście do programowania aplikacji WWW prezentowane przez ExtJS nie jest takie złe. Generalnie rzecz biorąc programowanie w środowisku przeglądarkowym mnie denerwuje. Po pierwsze dlatego, że jest to proces wtórny - ciągle robi się to samo. Po drugie dlatego, że taki schemat mnie bardzo ogranicza. Skrypt PHP ma ograniczoną pamięć i czas życia. Przy schemacie akcja-reload nie zawszę mogę sobie pozwolić na utrzymywanie jakichś danych, w stylu np. listy wpisów w danej kategorii. Problem polega na tym, że po zmianie któregoś z w/w wpisów muszę na nowo przeładować całą ich listę… Po trzecie - takie podejście bardzo obciąża system operacyjny serwera. Pół biegy jeśli wpisów jest 10, ale w momencie gdy jest ich 10000 to już nie jest tak fajnie. Ładowanie tych samych danych kilkadziesiąt razy pod rząd (jeśli nie więcej) powoduje jazdę na serwerze bazy danych, WWW, łączach itd. Po czwarte - tworząc aplikcję WWW muszę pamiętać o tym, że jej użytkownicy będą używać wielu systemów i wielu przeglądarek. Idzie za tym konieczność przystosowania kodu HTML i CSS do takiego scenariusza. Wyobrażacie sobie profesjonalny panel administratora jakiegoś serwisu, który się wywala pod IE?

Pod tymi względami aplikacje systemowe niszczą aplikacje WWW. Dobry projekt interfejsu graficznego pod kątem przenośności to kwestia dużo krótszego czasu niż przystosowanie szablonu do wszystkich przeglądarek. Aplikacja dysponuje nieporównywalnie większymi zasobami od sryptu na serwerze. Ponadto o np. podział listy wpisów na strony dba system, podczas gdy moim zmartwieniem jest tylko przekazanie do odpowiedniego komponentu odpowiednich danych. Jeśli tych danych jest dużo to mogę je buforować i doczytywać na żądanie. Do tego dochodzi prosta interakcja z użytkownikiem - system sam generuje okna dialogowe, dba o ich wyświetlenie. Ja muszę mu tylko powiedzieć co i kiedy ma się wyświetlić.

Większość z tych problemów eliminuje Ext. Niestety także i w tym przypadku aktualne zostają problemy z poprawnym wyświetlaniem tworzonych przez program elementów. Taka już natura HTML’a, z którego korzysta Ext. Nie zmienia to jednak mojego podejścia do programowania WWW. Wyżej wymienione negatywy powodują, że nie mogę już się doczekać rozpoczęcia prac nad moim CMS’em. Ma to być system, w którym panel administratora będzie natywną aplikacją Mac OS X a frontend standardową stroną napisaną w PHP. Nie ukrywam, że kusi mnie napisanie czegoś takiego w Ext’cie. Byłoby to z pewnością ciekawe doświadczenie, ale wolę mój wolny czas poświęcić na stworzenie w końcu czegoś dużego na Maku. Poza kilkoma małymi aplikacyjkami i kilkunastoma skryptami AppleScript nie miałem jeszcze okazji poważniej korzystać z API Cocoa. Projekt własnego CMS’a jest idealny do nauki API OS X.

Pomimo porażki (wszak nie udało mi się osiągnąć założeń jakie przyjąłem) w tworzeniu “żółtych karteczek” nie żałuję tych kilkunastu godzin spędzonych przed komputerem. Być może kiedyś będę musiał z tych czy innych powodów bliżej zaprzyjaźnić się z Ext’em. Jeśli tak to mam już jakieś podstawy i umiem poruszać się po dokumentacji API…