09 lutego 2008

Upiększanie URLi w Wicket

Udało się ożywić Daniela w mojej krucjacie ku wicketowemu dobru i w poprzednim wpisie Wicket prościej z mavenowym archetypem wicket-archetype-quickstart skrócił moją bolączkę z rozpoznawaniem tematu upiększania URLi w Wicket.

Od razu po tym jak Daniel wskazał na UrlCodingStrategy w Wicket postanowiłem zabrać się za temat. Okazało się, że on już mnie oczekiwał w rozdziale 3. Developing a Sample Application książki Pro Wicket (Apress). Przeskoczyłem rozdział 2 i zabrałem się za 3. Szczęśliwie temat upiększania w Wicket to trywialna sprawa, więc po niewielkiej zmianie w aplikacji mamy i ten temat "z głowy". Wystarczy wprowadzić do klasy aplikacji następującą zmianę.
package pl.jaceklaskowski.wicket;

import org.apache.wicket.protocol.http.WebApplication;

public class WicketDemoApplication extends WebApplication {

protected void init() {
// upiększ URLe
mountBookmarkablePage("/home", HomePage.class);
}

public Class getHomePage() {
return HomePage.class;
}

}
Kluczem jest skorzystanie z metody org.apache.wicket.protocol.http.WebApplication.mountBookmarkablePage, która związuje "przyjemniejszą" nazwę z wybraną stroną. Od tej pory adres http://localhost:8080/wicket-demo/home wskazuje na stronę HomePage. Oczywiście pojawia się problem, jeśli tych stron jest więcej, ale szczęśliwie w wicketowym WebApplication mamy do dyspozycji inne dodatki jak mapowanie wszystkich stron z wybranego pakietu java do wybranego adresu po nazwie klasy, co w naszym przypadku skończyłoby się na /pages/HomePage, jeśliby założyć, że pages to właśnie ten adres grupujący.

Jest jedno ale, które nie daje mi spokoju, a zwrócił na to uwagę Waldi w swoim Wicket po godzinnej przygodzie - moje trzy grosze... - kto odpowiada za konstruowanie przepływu? Programista javy czy twórca stron HTML? W przypadku JSF "pałeczka" była po stronie programisty, który manipulował faces-config.xml. W GWT jest podobnie, to programista dyktuje warunki (zresztą robi wszystko). Może więc tak musi być? Może to sprawa programisty, a strony to jedynie strony i nie one dyktują warunki działania aplikacji. Chciałoby się jednak deklaratywnie określać przepływy i powiązania między stronami a umieszczenie ich w kodzie java nie upraszcza sytuacji. Zobaczymy później. Na razie nie mogę już doczekać się, aż dojdę do poziomu rozpoznania Wicketa równym Danielowi, który połączył Wicketa ze Spring Framework i OSGi (!) To musi być dopiero zabawa. Can't wait till I'm there! ;-)

p.s. Nieśmiało przypominam o konkursie Blog Roku 2007, w którym po zmianach Notatnik plasuje się na 10. miejscu z 62. głosami. Możesz to zmienić, do czego gorąco zachęcam. Wysyłasz SMSa o treści B00248 pod numer 71222 i dalej cieszysz się lekturą moich przeżyć z dżawką i takimi tam pobocznymi sprawami. To jak, SMS wysłany? Termin upływa 19 lutego 2008, o godz. 12.00. Mikroby i iPody na razie rulez.

1 komentarz:

  1. Pytasz: "kto odpowiada za konstruowanie przepływu?". Zależy co rozumiemy jako ten "przepływ" :). Jeżeli chodzi o przechodzenie między stronami, czyli m.in. co ma się stać po wybraniu jakiegoś linka, to ja odpowiem przekornie: to powinien zaprojektować nie web designer, nie programista, ale raczej "interaction designer" :). Programista (chodzi mi o funkcję, a nie o osobę) owszem musi od strony technicznej umieć to obsłużyć, ale to nie on powinien projektować sposób interakcji użytkownika z aplikacją. Niestety często właśnie tak bywa i systemy bywają przez to mało wygodne w użyciu, nieergonomiczne, nieintuicyjne, itd.

    Rozróżniłbym generalnie dwa rodzaje przepływów: jeden to po prostu standardowa nawigacja w aplikacji, czyli linki w menu, linki np. na obiekcie, które powodują przejście do przeglądu jego szczegółów, itp. Drugi rodzaj to takie przepływy, które definiują jakiś ciąg operacji do wykonania, takimi są często operacje edycyjne, np. ciąg kroków prowadzący do dokonania zakupów w sklepie internetowym. W samym Wickecie ten drugi rodzaj przepływów można najprościej zrobić np. w oparciu o komponent Wizard z wicket-extensions, inni zaprzęgają do tego jakieś silniki workflow (np. jBPM). Czyli ogólnie można wszelkie przepływy zakodować wprost w Javie, można też je zadeklarować gdzieś "na zewnątrz" - czyli jak komu pasuje. Wydaje mi się, że nie jest tu głównym problemem, czy to będzie zadeklarowane (celowo używam tego słowa!) w Javie, czy zadeklarowane w xml'u (vide faces-config z JSF), czy jeszcze jakoś inaczej. Chodzi raczej o to, by było to zapisane w jednym miejscu, a nie rozsiane po całej aplikacji. Wtedy łatwiej takimi przepływami zarządzać, modyfikować je, itd. Ale czy tak naprawdę zapis tego w Javie nie jest pewną formą "deklaracji"? Czym się różni deklaracja w xmlu od deklaracji w Javie - inna jest forma zapisu, no i ewentualnie kod Javy trzeba kompilować. Ten drugi argument można jednak spokojnie pominąć w systuacji, gdy użytkownik końcowy aplikacji nie ma możliwości modyfikowania konfiguracji przepływów (a pewnie w większości sytuacji tak przecież jest). A kodem w Javie chyba łatwiej zarządzać i go refaktoryzować, niż kod w xmlu. Zresztą nawet twórcy Springa zwrócili na to uwagę, stąd m.in. projekt "Spring Java Configuration" - by konfigurować beany springowe wprost w Javie.

    Co do połączenia Wicketa, Springa i OSGi, to naprawdę nie jest to bardzo trudne i nie jest to jakiś bardzo wysoki "poziom" zaawansowania :). Po prostu trzeba mieć na to dłuższą chwilę, aby zebrać to wszystko razem: "zabundlować" Wicketa, dodać te kilka klas o których wspomniałem i odpalić to np. pod Eclipsem (chyba najprościej). Z samym Springiem nic specjalnego nie trzeba robić, bo jest on dystrybuowany już od pewnego czasu w postaci bunldi OSGi (bo w końcu to zwykłe jary, tylko z dodatkowymi wpisami w manifeście).

    Pozdrawiam i życzę smaczniejszych śniadań ;)

    OdpowiedzUsuń