czwartek, 21 października 2010

Turbo Seam

Niniejszy post rozpoczyna mini serię poświęconą Seam Framework. Zawartość to kilka przydatnych technik oraz kilka trików, które udało mi się zebrać podczas paru lat używania tego "ficzer"-worka.

Spis treści

- Produktywne środowisko developerskie. Hot deploy wszystkiego. Nawet encji (a podobno się nie da;P) W najgorszym przypadku 3 sek. na przeładowanie.
- Integracja z Maven - elegancko i bezboleśnie. Panom od JBoss Tools już podziękujemy...
- Integracja z jQuery - gdy ciężar RichFaces przygniata, narzut na komunikację AJAX osłabia a kontrolki wyglądają jak z poprzedniej epoki
- Asynchroniczny mailing w dobrym stylu - mikro architektura rozsyłania maili połączona z eleganckim decoupliniem poprzez zdarzenia
- Integracja z BIRT - speszyl haki
- Seam Gen i Seam App. Framework - dlaczego nie używać:)


Powyższa lista będzie sukcesywnie aktualizowana o linki do konkretnych postów oraz ew. nowe pozycje. Docelowo post będzie stanowił swego rodzaju spis treści.

//==============================

Generalnie do tej pory nie pisałem zbyt wielu postów technicznych - wychodząc z założenia, że w oceanie treści nie będą wnosić nic nowego.

Jednak zestawiając dwa aspekty:
- własne przemyślenia
- obserwując jak Seam jest używany
doszedłem do wniosku, że zgromadzona wiedza może się komuś przydać.

Jeżeli macie jakieś tematy, które chcielibyście poruszyć - piszcie śmiało, być może dodamy je do listy.

14 komentarzy:

iirekm pisze...

> - Integracja z Maven - elegancko i bezboleśnie. Panom od JBoss Tools już podziękujemy...

Już dawno nie używałem JBoss tools ale kiedyś miał 'konektor' z serwerem JBoss o wiele lepszy od tego standardowego i miał też graficznego buildera stron jak ktoś lubi. Ale oczywiście bez JBoss tools aplikacje Seamowe też można łatwo budować.


> - Integracja z jQuery - gdy ciężar RichFaces przygniata, narzut na komunikację AJAX osłabia a kontrolki wyglądają jak z poprzedniej epoki

Nie wiem jak to napisać by nie robić negatywnej reklamy twojej serii artykułów: Właśnie z tego powodu jak kłopotliwie się w JSF, Seam czy Spring MVC robi "bogate" GUI, nie przepadam za tymi frameworkami, i wolę frameworki takie jak GWT, Vaadin czy Flex, gdzie tworzenie "bogatego" GUI niewiele się różni od tworzenia zwykłych aplikacji dla Swinga.

Sławek Sobótka pisze...

Wg mnie w niemałym projekcie bez JBoss Tools jak bez ręki. Chodzi o to, że edytor xhtml po kliknięciu w nazwę użytego komponentu potrafi przenieść mnie miejsca skąd jest on wystrzyknięty, czy to będzie @Out, @DataModel, @Factory, @Unwrapp. Do tego dochodzi podpowiadanie składni w XHTML nawet dla zmienny pomocniczych w iteracji np przy tabelkach.

Chociaż z drugiej strony zamula system niemiłosiernie:)

Co do bogatego GUI, to jak zwykle masz poniekąd rację, ale co gdy:
- team ma doświadczenie w pewnych bibliotekach i potrafi robić tam cuda wianki?
- mamy zastaną aplikację w Seam i trzeba tylko dodać nieco wisienek na torcie?

Marcin Niebudek pisze...

Ja będę czekał na JQuery z Seamem :-) bo RichFaces faktycznie potrafi przygnieść...

Do tej pory szliśmy raczej w kierunku Seam Remoting + Prototype + Scriptaculous, ale JQuery kusi, więc chętnie się czegoś dowiem.

Generalnie ja bardzo lubię Seam'a, Facelety uwielbiam za ich użyteczność i prostotę, a model eventów i obserwatorów także jest jednym z lepszych elementów tego framewoku.

Także czekam na ciąg dalszy serii :-)

Krzysiek pisze...

O dobrze, mało o Seam w polskiej sieci. Jeśli jeszcze wspomnisz o Seam - Wicket i Seam - Groovy to będzie jeszcze lepiej ;)

Paweł Piątkowski pisze...

Bardzo ciekawy temat. Myślę, że warto było by mu poświęcić spotkanie LJUG'a.

Sławek Sobótka pisze...

Ehhh minęło 2 miesiące i niestety nie dałem rady napisać żadnego konkretnego posta z wymienionej listy:P

Po prostu ostatnie 2 miesiące spędzam w hotelach - w łikendy przepakowuję walizki w domu:)

Mam nadzieję, że na początku roku znajdę chwilę czasu, aby spisać doświadczenia z wymienionych punktów.

Chyba, że priorytet na blogu zdobędzie Android:)

Co do lJUGa to proponuję zarzucić temat na forum... jeżeli znajdą się chętni, to możemy zorganizować salę i spotkanie.

Anonimowy pisze...

Może Seam na wiosnę?

Sławek Sobótka pisze...

Tak... cały czas pamiętam o tym rozpoczętym "mini projekcie" na blogu...

Póki co najwyższy priorytet mają prezentacja na 33rd degree i 4 developers.

Ale jeżeli masz jakiś konkretny temat, o którym chciałbyś w najbliższym czasie poczytać to napisz - tylko nie anonimowo:P

gali pisze...

Na pierwszy ogień proponuję

Produktywne środowisko developerskie. Hot deploy wszystkiego.

Również chętnie poczytam o współpracy GWT z SEAM ;)

Sławek Sobótka pisze...

Co do GWT to niestety nie mam w nim nawet dostatecznej biegłości, więc nie chcę tworzyć postów w stylu "wczoraj próbowałem i coś mi czasem działa".

Co do środowiska, to mam na myśli Tomcata + plugin firmy sysdeo (darmowy).
Jeżeli ktoś potrzebuje EJB to wciąż sugerowałbym development warstwy prezentacji na Tomkacie z sysdeo.

Przy dobrym rozwarstwieniu EJB można sobie developować na boku - zresztą... najbardziej racjonalne w środowisku developerskim jest podłączenie się do EJB teścikiem (aby nie klikać jak szympans 100x dziennie w to samo).

Ale to wszystko przy dobrym rozwarstwieniu, czyli gdy nie wydurniamy się robią z session beanów komponentów warstwy prezentacji (kontrolerów, akcji czy czegoś w tym stylu).

Przemek pisze...

Dlaczego Tomcat i plugin jeżeli dzięki Jboss Tools można za pomocą zwykłego Crt + S zapisać zmiany w widoku i automatycznie przeładować dany widok w Jboss ? Dlaczego w ogole oddzielnie stawiać Tomcata ?

Jeżeli chodzi o development EJB to czy mozesz rozwinać "podłączenie się do EJB teścikiem" ?

Sławek Sobótka pisze...

Odpisze w piatek z domu bo mam przy sobie tylko tel i ciezko mi pisac elaborat na androidzie:-)

Sławek Sobótka pisze...

Przypomniałem sobie o tych pytaniach...

JBoss tools działa tak, że przy każdym ctrl+s robi deploy aplikacji do tempa. Zmianę tempa zauważa serwer i zależnie od zmiany przeładowuje aplikację.

Problemy: czasochłonność, periodyczne wykrzaczanie się serwera, przy integracji z mavenem przez M2 co kilkanaście godzin całe środowiska się sypie i trzeba je magicznie czyścić. Do tego HotDeploy nie działa dla EJB i z tego co piszą developerzy Jbosa nie należy się spodziewać takiego ficzera. Zwrot inwestycji byłby niekorzystny - czytaj: musimy przepisać serwer;P

Tomcat plugin formy sysdeo dostarcza swojego classloadera. Jest on na tyle cwany, że pobiera zmienione (świeżo sompilowane) klasy wprost z workspace. bez pośrednictwa katalogu tymczasowego na deploy. Rezultat: szybko, stabilnie i do tego przeładowują się również encje! Co jest niemożliwe na jbosie.

Konsekwencją użycia tomcata jest odcięcie się od EJB.

Dlatego napisałem, że jeżeli potrzebujemy EJB to warto postawić sobie 2 produktywne środowiska. Prezentacja na Tomkacie a ciężka logika biznesowa w ejb na jbosie. Takie założenie miała kiedyś zresztą architektura EE, zanim zaczęto ją wciskać małym softwarehausom do młaych projekcików. Obie częsci można sobie produktywnie rozwijać w odpowiednich do tego środowiskach. Klientem do EJB może być np test (a nie gui) dzięki czemu development jest ultra-produktywny bo nie trzeba klikać jak szympans po gui aby odpalić kawałek biznesu.

Ale takie podejście wymaga bardziej zaawansowanej architektury, a ta znowu opłaca się dopiero przy średnich i dużych systemach.

Przemek pisze...

dzięki za wyczerpujące wyjaśnienie. BTW szkoda że Blogger nie dostarcza funkcji w stylu "Moje komentarze do bloga". Łatwiej byłoby śledzić odpowiedzi...