Jakiś czas temu Michał Mech pisał o tym jak można rozkładać komponenty w Swingu przy pomocy Group Layoutu. Dzisiejszego dnia mam zamiar pokazać Wam drugą stronę medalu - mianowicie Form Layout, który można wykorzystać przy tworzeniu aplikacji w SWT.
Chciałbym dzisiaj poruszyć dość ważną kwestię, jaką bez wątpienia jest rutyna i frajda z pracy. Motorem dla mnie była głównie rozmowa, którą odbyłem dzisiaj z kolegami, gdy siedząc przy piwie dyskutowaliśmy na temat alternatyw i sposobów wzbudzania w sobie entuzjazmu. Może na początku kilka definicji zaciągniętych ze słownik języka polskiego wydawnictwa PWN.
Praktyka W tym miejscu bazuję na swoim bądź co bądź skromnym doświadczeniu, które nabyłem pracując w AGI. Była to pierwsza firma, w której spotkałem się z wykorzystaniem testów jednostkowych. Pamiętam do dzisiaj walki o 70% pokrycie kodu testami. :). Nie mniej, nie robiliśmy tego tylko po to by zobaczyć zielone słupki w raporcie wygenerowanym przez PHP Unit. Takie pokrycie kodu testami gwarantuje znaczne ograniczenie błędów wychodzących z czasem, głównie dlatego, że znajduje się już podczas pisania testów.
Jakiś czas temu postanowiłem zmienić myśl przewodnią bloga. Zapewne nikt nie zauważył tego, że zniknął tekst “żubr powstaje z jęczmienia” na rzecz “Pragmatyzmu kontrolowanego”. Czym było to podyktowane? Ano tym by tą gromadę różnych not, nie zawsze łączących się ze sobą tematycznie, podeprzeć myślą, jaką jest poszerzanie horyzontów i dzielenie się zdobytymi z biegiem czasu doświadczeniami.
Od jakiegoś czasu na forum.php.pl spotykam się z różnymi zdaniami na temat interfejsów i klas abstrakcyjnych. Argumenty, które czasami się trafiają są chybione. Zacznijmy od tego, że trzeba potrafić rozróżnić interfejs od klasy abstrakcyjnej, to nie to samo! Interfejs jest najwyższym poziomem abstrakcji, który definiuje nowy, wolny od implementacji typ. Bez jakiejkolwiek linii kodu, tylko sygnatury metod publicznych. Klasa abstrakcyjna jest już początkiem konkretnej implementacji, zawiera kod ogólny i wymusza w klasach dziedziczących dorzucenie konkretnych metod, które są specyficzne, inne, różne. Mogą trafić się takie przypadki, że klasa abstrakcyjna zawiera 5 metod, a jej pochodne tylko jedną. Czy jest to uzasadnione? Oczywiście. Ta jedna metoda determinuje nowy typ, który jest jawną specjalizacją.
Pierwsze błędy Pamiętam swoje pierwsze implementacje MVC, w czasach gdy słowo framework nie było jeszcze trendy a wiele osób, w tym i ja, nawet go nie używało. W owych pierwszych implementacjach MVC model był pewnego rodzaju fasadą, która zapewniała dostęp do danych. Problem polegał na tym, że kod np klasy User wyglądał następująco:
Mam niebywałą przyjemność oznajmić, że dnia 23 lutego zostało wydane, jak sam tytuł posta wskazuje, Agavi 0.11 RC3. Do pierwszej, w pełni stabilnej wersji jest już coraz bliżej. Zgodnie z rozkładem jazdy został otwarty jeden ticket, którego realizacja została odsunięta na sam koniec. Mianowicie, opis migracji z wersji 0.10 do 0.11. Ogrom zmian, które przetaczały się przez trunk repozytorium mógł przyprawić o zawrót głowy. Zmiany z rewizji na rewizję potrafiły w jednym momencie zniszczyć skrzętnie budowane narzędzia, które opierały się na zmieniających się wciąż mechanizmach. Co zyskało Agavi o wersji 0.10? Przede wszystkim developerzy uwolnili projekt od niezręcznej i nieporęcznej konfiguracji w plikach INI, która poza łatwością odczytu nastręczała przede wszystkim problemów… a to brak hierarchiczności, brak możliwości łączenia konfiguracji, w końcu brak narzędzia do walidacji zapisanych danych. W poście " Dlaczego konfiguracja w XML" porównywałem XML również do YAMLa. Sporą zmianą, naturalnie, na lepsze było zrezygnowanie z tradycyjnego flowu Mojavi 3. Do tej pory wyglądało to w ten sposób, że każda akcja miała metodę getRequestMethods, która zwracała informacje o tym w jaki sposób dostępna jest akcja. Czy to GET, POST, bądź cokolwiek (odpowiednie stałę w klasie Request - GET, POST, NONE). Teraz o sposób dostępu do akcji determinuje nazw akcji. Akcja o nazwie executeRead będzie wykonana w chwili żądania typu GET. Metoda o nazwie executeWrite będzie wykonana w chwili gdy otrzymamy formularz via POST. Metoda execute będzie wykonywana zawsze (o ile walidacja przebiegnie bez zakłuceń). Zysk z tego jest taki, że implementacja różnych kontrolerów nie wpływa na kształt akcji. W chwili gdy wiązały się z tym stałe GET/POST implementacja wywołań z poziomu konsoli była ciężka. W zapowiedziach pojawia się ConsoleRequest, ponieważ z Agavi 0.11 wyleciały kontrolery zależne od kontekstu. Jest jeden Controller, różne są implementacje requestu vide ConsoleRequest (jeszcze niegotowy, będzie w 1.0), WebRequest oraz SecureWebRequest. W międzyczasie pożegnaliśmy również stałe View::SUCCESS, ERROR, INPUT, ALERT, a metoda getDefaultViewName każdej akcji zwraca po prostu suffix do nazwy widoku (np. metoda akcji “Cart” zwraca wartość “Product”, stąd klasa widoku to CartProductView). Co więcej w połączeniu z innym mechanizmem Agavi, Output types, zmiany formatu widoku oraz języka nie wiążą się z implementacją bądź powielaniem logiki biznesowej. Implementujemy tylko logikę związaną z widokiem. Warto również wspomnieć, że od tej chwili metoda Controller::forward(module, action) jak i samo używanie powiązanych akcji jest odradzane, jako źródło potencjalnych problemów (dlaczego widok nie jest uruchamiany) tym bardziej, że tworzenie widoków i akcji załatwia samo Agavi przez taski dla Phinga. W chwili, gdy chcemy użyć innego widoku, spoza tych, które dostarcza sama akca po prostu zwracamy array(module, view name, parameters). Zniknęła również możliwości zrobienia forwarda z widoku (ogólnie problemy z request methods, to co było post-only nie szło przy fowardzie przy żądaniu otrzymanym via get), co wydaje się jak najbardziej uzasadnione. Widok nie jest organem decyzyjnym, który powinien wskazywać na wykonanie logiki biznesowej. Nie mniej jest możliwość przekierowania do widoku innej akcji.. poprzez redirect bądź poprzez zwrócenie array(module, view name, parameters). ...
Jedną z nowości jaką niesie Agavi w wersji > 0.10 jest mechanizm output types. Jest to bardzo proste rozwiązanie, które umożliwia uniknięcie gimnastyki z tworzeniem widoków w różnych technologiach, z którymi wiąże się różna logika. Banalny przykład. Te same dane prezentujemy w postaci HTML jak i PDF a do tego możemy je pobierać przez XmlHttpRequest. Dane są praktycznie identyczne, różny jest format wynikowy i proces jego tworzenia. Dla zwykłej strony wskazujemy szablon, dorzucamy dane i koniec, dla XmlHttp zwracamy JSONa. Stworzenie outputu w formacie PDF nie będzie tak proste jak pozostałych, ponieważ konieczne będzie stworzenie układu strony, dorzucenie fontów etc. Ogólnie w żaden sposób nie da się połączyć tych formatów w jednym widoku bez sporej ilości warunków i “protez”. By uniknąć zakopania się w tym wszystkim zwykle tworzy się dodatkową akcję, która w sporej części pokrywała się z pierwotną a różni się tylko widokiem i szablonami. Począwszy od Agavi 0.11 problem przestaje istnieć. ...
Wiele razy spotykałem się z negatywnymi opiniami na temat Propela. Przyznaję, nie jest to narzędzie doskonałe, ale bez wątpienia, w tej chwili jest to wiodący ORM dla PHP. Jedną z wad Propela, która pojawia się chyba najczęściej jest XML i definiowanie tabel w pliku XML. Otóż drodzy moi, nie jest to konieczność. Schemat z istniejącej bazy danych można bez problemu przenieść do XMLa a następnie bez najmniejszego problemu wygenerować z niego klasy. Możemy zrobić to dwoma poleceniami. Pierwsze jest dostępne po instalacji przy pomocy PEARa, drugie przy korzystaniu z Phinga: ...
Singleton jest chyba pierwszym z “wzorców projektowych” jaki wszyscy poznaliśmy. Prosty w implementacji, jeszcze łatwiejszy w użyciu, ale pociągający za sobą stos negatywnych konsekwencji. W poszukiwaniu informacji i zdań o singletonie w polskim internecie trafiłem na Wikipedię, gdzie znalazłem zdanie, które podsumowało to czym jest tenże “wzorzec”: Singleton jest też uznawany za antywzorzec, gdyż często jest tylko eufemizmem dla zmiennej globalnej. W książce " Refaktoryzacja do wzorców projektowych" padają kolejne dwa ważne zdania: ...