Home > Polish > Metaprogramming zamiast konwencji nazw

Metaprogramming zamiast konwencji nazw

Tak chwalę wam i chwalę konwencję nazw i jak to fajnie jest ją mieć, a każdy chyba wymieni mi przykłady, że czasem nie jest to najlepszy pomysł by tylko na niej polegać. I co jak ktoś chce mieć własne nazwy metod lub co gorsza, wykonuje legendarną zmianę wszystkich frameworków bo ma pojo klasy. Czy taka osoba jest skazana na zmienianie nazw po wsze czasy?
Nie. Nasz dzielny bohater nie jest stracony, gdyż dziś pozna tutaj inne sposoby informowania na oznaczanie ważnych metod w cyklu życia strony/requestu.

Nasi dzisiejsi bohaterowie to adnotacje i zostali przedstawieni javie w jej 5tym wydaniu. Są już dość długo na rynku, ale do dziś wielu nie może ich zaadoptować. Natomiast tapestry z racji bycia nowym frameworkiem rozpoczęło swój żywot przyjmując w pełni ich dobrodziejstwo.

Adnotować możemy wiele rzeczy, pola, metody, konstruktory itd. Kilka adnotacji nawet już się na blogu pojawiło, mimo iż starałem się ich za wcześnie nie pokazywać. Streśćmy więc może co już znamy i co jeszcze przyjdzie nam poznać lepiej.

@Persist – tę adnotację już znamy. Umieszczona nad polem powoduje, że strona zachowuje się jakby posiadała stan (a teoria mówi, że HTTP jest bezstanowe). Zapisywane wartości pakowane są do mapy i wsadzane do sesji użytkownika. Każda z wartości jest związana dzięki temu z danym użytkownikiem, stroną i konkretnym polem a Tapestry troszczy się o to by nie pojawiły się te informacje nigdzie indziej. Poprzez atrybut value adnotacji można doprecyzować zachowanie podczas zapisu.

@InjectPage – również znamy, umieszczone nad polem wstrzykuje obiekt strony o klasie tej samej co pole. Pozwala to nam przekazywać wartości i nawigować pomiędzy stronami. Adnotacja posiada opcjonalny atrybut, informujący o konkretnej instancji strony do wstrzyknięcia. Do użycia w przypadku gdy klasa pola jest interfejsem implementowanym przez stronę. Dość to naciągane, ale i taką opcję mamy.

To teraz nowe zabawki. Poznaliśmy już metody  onActivate i onPassivate. Działają dobrze, ale strasznie upierdliwe są i dużo pisać trzeba przy nich. No więc dla leniwych (jak ja) mamy adnotację

@ActivationRequestParameter – Można nią adnotować jedno pole jedynie, ale dla większości będzie to wystarczająco. Jeśli jest to własny obiekt (nie string, bool etc) to potrzeba będzie dostarczyć translatora (tak jak w przypadku onActivate i onPassivate). Wyjątek stanowią encje hibernata, dla których tapestry samo tworzy translatory (o ile mamy bibliotekę integrującą tapestry z hibernatem w naszym projekcie)

Zmniejszając ilość kodu w naszej aplikacji trudno jest nie zauważyć wszystkich metod get i set jakie  powstają by wspierać templaty .tml. No więc czas i to usunąć przy pomocy adnotacji @Property. Generuje ona dla prywatnego pola gettery i settery. Dodatkowo, korzystając z atrybutów adnotacji, możemy ustawić by tapestry generowało tylko getter/setter w przypadku gdy drugą metodę stworzymy sami bądź gdy nie chcemy by takowa była dostępna w aplikacji.

Pamiętacie naszą metodę setupRender(){} ? Otóż okazuje się, że dobrze by było gdyby się nazywała init(){} a nad nią dało się umieścić adnotację @SetupRender. I wiecie co? Da się :) Każda z metod cyklu życia strony ma swój odpowiednik w adnotacji.

Programując w tapestry natkniemy się na o wiele więcej adnotacji, lecz pozwólcie mi zostawić kilka na przyszłe wpisy, gdy będę zajmować się związanymi z nimi pojęciami. Poza tym wpis mi się robi długi ;)

Do następnego

 

PS nie twierdzę, że konwencja nazw jest zła. Wręcz przeciwnie, lubię ją, ale nie zawsze jest ona najlepszym wyjściem. Do pisania na szybko preferuję nazywać moje metody zgodnie z konwencją, gdyż tak mi jest łatwiej (tak, tak onActionFrom też któregoś dnia zamienimy na adnotację). Później natomiast to już różnie bywa. Moja rada: dogadajcie się w teamie jak wam bardziej pasuje programować. Tapestry się do was dostosuje :)

Advertisements
Categories: Polish Tags:
  1. 08/12/2010 at 23:28

    Te adnotacje, które dzisiaj omówiłeś posiadają odpowiednik w kodzie w poprzednich wpisach. Planujesz przy omawianiu następnych posiłkować się kolejnymi etapami tworzonego w pierwszych wpisach projektu lub też osobnymi kawałkami kodu oderwanymi od niego? Było by znacznie łatwiej dla czytelnika bez znajomości Tapestry zorientować się w tym co się dzieje.

    I drugie pytanie – planujesz robić wpisy o integracji Tapestry z Hibernate/Spring?

    • 09/12/2010 at 20:29

      Idealnie by było gdybym pisał jakąś aplikację, ale to było by zbyt pracochłonne. Postaram się jednak trzymać jakiejś w miarę spójnej koncepcji, którą będzie widać od wpisu od wpisu o formularzach, tak żebym miał już jakąś liczbę narzędzi do pracy. Pewnie coś na wzór mantisa będę tworzył, ewentualnie jakiejś TODO listy bo to dość prosta koncepcja.

      Integracja będzie opisana, jak najbardziej. Jednak do tego jeszcze trochę wody w wiśle upłynie. Osobiście uważam, że integracja z Springiem to nie jest jakiś priorytet, o ile nie chcemy podpiąć jakiejś technologii z którą on się łatwo integruje.
      Hibernate będzie szybciej, ale wpierw komponenty :)
      Z innych integracji będzie też pewnie jsecurity (znaczy obecne Apache Shiro), ale to też wymagać będzie czasu trochę.
      Jeśli chcesz korzystać z T5 już dziś to zacznij od studiowania jumpstart (link na głównej stronie tapestry znajdziesz, ewentualnie w moich prezentacjach powinien być). Jest tam mnóstwo przykładów + można zobaczyć, że Tapestry może współgrać z EJB (bo Geoff korzysta z EJB wszędzie).

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: