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:
> - 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.
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?
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 :-)
O dobrze, mało o Seam w polskiej sieci. Jeśli jeszcze wspomnisz o Seam - Wicket i Seam - Groovy to będzie jeszcze lepiej ;)
Bardzo ciekawy temat. Myślę, że warto było by mu poświęcić spotkanie LJUG'a.
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.
Może Seam na wiosnę?
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
Na pierwszy ogień proponuję
Produktywne środowisko developerskie. Hot deploy wszystkiego.
Również chętnie poczytam o współpracy GWT z SEAM ;)
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).
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" ?
Odpisze w piatek z domu bo mam przy sobie tylko tel i ciezko mi pisac elaborat na androidzie:-)
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.
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...
Prześlij komentarz