18 Jan 2005
I'm above, claiming unconditional love. Tak mógłbym nazwać swój frejmłork, ale jest trochę długie i nie wygodne. Bieżąca nazwa ma natomiast cząstkę PHP, więc nie nadaje się z przyczyn licencyjnych. Anyways, jest to zapowiedź biblioteki widgetów sterowanych wyłącznie zdarzeniowo dla PHP. Powstał z potrzeby chwili (trwającej od listopada) w odpowiedzi na brak odpowiednich narzędzi do obsługi prezentacji (PHPGTK wykluczam jako bibliotekę client-side). rwf jest ciężkie jak każdy MVC, Prado zupełnie nieodpowiada specyfice pewnego zadania, ponadto jest zorientowane layoutowo/markupowo, wprowadza nawet na ten cel własny język opisu. Potrzebna była czysto obiektowa biblioteka reagująca na zdarzenia (paradoksem jest, że choć sam protoków HTTP jest wybitnie zdarzeniowy, to brak gotowych do powszechnego stosowania silników eventowych dla PHP). Nie było, więc zacząłem pisać.
Program napisany w wykorzystaniem PHPTK (nazwa do zmiany) wyglądać może tak. A tak działa. Fakt, że nie ma tego jeszcz zbyt wiele i może nie robię dobrze ogłaszając i deklarując coś już teraz, ale zaczynam spowalniać a wydaje mi się, że biblioteka może okazać się przydatna.
Na razie bez pozostałych źródeł ani tutoriali. Może ktoś podeśle jakieś cenne uwagi..
- Jajcus
Problem w tym, że tworzysz całe drzewo wigetów aby następnie obsłużyć jedno zdarzenie. Nie jest to zbyt optymalne, ani IMHO bardzo eleganckie.
Framework powinien być na wyższym poziomie niż kod obsługujący żądania z przeglądarki -- tak aby żądanie trafiało do odpowiedniego kodu. Jak robisz <form action="akcja"/> to ma sie wykonać "akcja" i kod obsługi innych zdarzeń jest tu zbędny. Jednak Twoje rozwiązanie ma niewątpliwego plusa w postaci jednolitego opisu interfejsu wraz z przypisanymi mu działaniami. W przypadku typowych aplikacji "z pętlą główną" to się sprawdza bo nie ma niepotrzebnych narzutów, w przypadku protokołu bezstanowego mniej.
Nie lepiej po prostu traktować skrypty PHP w przestrzeni adresowalnej poprzez URL (bezpośrednio lub przez jakiś skrypt przetwarzający zapytanie) jako funkcje obsługi zdarzeń (w których wyniku powstają dokumenty) zamiast jako dokumenty? To jest bardziej zgodne z założeniami protokołu HTTP i języka HTML. Ale racja -- będzie wyglądać mniej elegancko. W Zope w każdym razie mi się to sprawdza, ale tam też engine robi dużo za mnie.- str()
Zapewniam Cię, że nawet dla dość rozbudowanych projektów tworzenie za każdym przebiegiem struktury widgetów nie jest problemem. W tej chwili mam w pracy pod ręką (clickety click) 284 pliki klas, co stanowi ok 1/4 całego repo - ok 1000 klas. Za jednym zamachem jest inkludowanych ok 100 klas (jeden z 10 modułów projektu). Wszystko chodzi tak samo żwawo jak Hello World pobierane z bazy i wyświetlane przez Smarty (w pracy <1s, na domowym 2xC433 ok. 2s).
Co do elegancji.. hmm, można się spierać. Sztywny podział czasu wykonania aplikacji na etapy tworzenia, obsługi zdarzeń, wizualizacji i niszczenia ma wiele zalet. Nie dochodzi _m.in._ do dzikich polowań na obiekty, których jeszcze nie ma (to poważny problem w obecnym projekcie - biblioteka bazowa jest napisana w sposób wysoce partyzancki ;-).
Co do oddzielenia silnika od aplikacji - masz rację. To co pokazałem to śmieciowe demo. Poprawnie działająca aplikacja powinna dziedziczyć po klasie Application, w której konstruktorze powołane zostają obiekty, a jej metoda run() obsługuje zdarzenia automatycznie. I to wszystko. Tylko definicje obiektów i zdarzeń. Nic ponad to. Rzekłbyś - niemal aplikacja client-side.
Przyznam, że sam miałem wątpliwości czy powoływać tak skomplikowaną strukturę za każdym przeładowaniem, ale widząc ile czasu tracę na śledzenie błędów (to własnych, to konsekwencji błędów innych) przekonałem się, że nie ma się co szczypać - niech klient kupi silniejszy serwer.
Co do zaporoponowanego przez Ciebie sposobu obsługi - przyznam, że nie bardzo łapię. Czy fragmenty kodu miałyby być włączane na podstawie URLa?
Acha, jeszcze względem "jedno zdarzenie" z pierwszego zdania. Ono nie jest jedno. To całkiem złożony system wyzwalających się wzajemnie zdarzeń. Gdy klikasz na Zakładkę wysyłasz jej sygnał Click. Funkcja, która jest domyślnie podpięta pod to zdarzenie generuje sygnał Select i wysyła sygnały Deselect do pozostałych zakładek. Nad przyzwoitą kolejnością obsługi sygnałów spędziłem niemało czasu.- Jajcus
Masz rację. Po prostu chiałem pokazać inny punkt widzenia. To jeden z możliwych model — czasem lepszy, czasem gorszy. A pisząc o całym łańcuchu zdarzeń przekonałeś mnie, że to ma jednak duży sens także w aplikacji WWW. Nieporozumienie wynikało z tego, że powołałeś się na HTTP i zasugerowałem się, że chodzi tylko o obsługę zdarzeń HTTP.
> Czy fragmenty kodu miałyby być włączane na podstawie URLa?
„włączane” — to takie „zboczenie” PHPowe. :-) Odpowiednie fragmenty kodu mają być wywoływane na podstawie URL. W normalnym serwerze aplikacji przecież i tak są cały czas skompilowane w pamięci ;-)
Ale to oczywiście dotyczy tylko zdarzenia przychodzącego z przeglądarki. Resztę łańcucha muszą załatwić inne mechanizmy.