🚀 go-pugleaf

Użyj Mavena i wygeneruj projekt z archetype'a - będziesz miał gotowca. 
Nie znam i nie używam Springa, bardziej w stronę Seam'a.
Osobiście wydaje mi się że najbardziej przyszłościowy "framework" jeśli 
można to tak nazwać to DeltaSpike, ale trzeba poczekać aż go napiszą ;)
Marx

Zrobiłem sobie wczoraj krótką przerwę i później udało mi się rozwiązać mój problem. Tak jak często wcześniej bywało szukałem tam gdzie kierowały mnie stack trac'y, ale to nie tam był problem tylko jego następstwa. Miałem niewłaściwego ViewResolvera, który nie radził sobie z utrzymaniem stanu beanów i automatycznym generowaniem właściwych url-i dla widoków. Tak czy siak, ruszam dalej z tym co wybrałem i pewnie jeszcze się odezwę :)

W dniu 2012-08-06 18:02, kaszpiro pisze:
> Od 4 dni bez skutku próbuję zintegrować PrimeFaces 3.X ze Springiem 3.X. O ile samo wyświetlenie komponentu PrimeFaces i danych np. z BackingBean-a działa (datatable), o tyle mam problem ze zrozumieniem mechanizmu mapowania adresów URL i przede wszystkich znalezienie rozwiązania, które pozwoli na poprawną współpracę Spring MVC z PrimeFaces - konkretnie wywołania ajaxowe. Zrobiłem prosty projekt bez Springa (JSF + PrimeFaces) i wszystko działa jak należy, ajaxowe wywołania z kontrolek działają i zawartość kontrolek się odświeża.
> Z tego co wyczytałem to Spring nie ma wbudowanej obsługi ViewScope (znalazłem jakieś obejście napisane przez autora PrimeFaces), ale nic to mi nie pomogło (nie wspominając już o tym, że na oficjalnej stronie PrimeFaces przykłady z ShowCase mają bugi, które uniemożliwiają uruchomienie niektórych przykładów - żenujące).
>

A Spring do czego Ci potrzebny?

Pozdrawiam,
Wojtek

> 
> A Spring do czego Ci potrzebny?
> 

Ano sam jeszcze nie wiem. Na pewno chciałem skorzystać ze Spring MVC, bo po przeglądnięciu Showcase'a wydał mi się interesujący i dający sporo możliwości jeżeli chodzi o obsługę żądań (np. odróżnianie metody żądania) oraz łatwe budowanie odpowiedzi wysyłanych do klienta (coś podobnego do tego czego używałem z Kohana PHP). Nie znam się na tyle, żeby stwierdzić czy to coś więcej niż daje sama Java EE 6, ale chciałem sam sprawdzić z czym to się je. No i oprócz Spring MVC zależało mi głównie na Spring Security. 
Chciałem mieć jak najwięcej podstawowych funkcjonalności, które powinna zapewniać aplikacja pisana w 21 wieku OUT OF THE BOX, ale na razie nie jestem przekonany czy ze Springiem faktycznie tak jest. 
Jednak tak właśnie buduje się swoją wiedzę i doświadczenie. Sporo się nauczyłem i z kilkoma problemami musiałem sam poradzić poznając jednocześnie technologię i kilka ciekawych blogów w necie :)
Na chwilę obecną zostaje przy moim wyborze i posuwam się powolutku dalej. Aktualnie obsługa formularzy...

W dniu 2012-08-14 22:17, kaszpiro pisze:
>>
>> A Spring do czego Ci potrzebny?
>>
>
> Ano sam jeszcze nie wiem.

Nie idź tą drogą :)
Pamiętaj, że technologie, frameworki, biblioteki nie są po to, by je 
stosować, ale są po to, by przy ich pomocy rozwiązywać konkretne 
problemy. Czyli najpierw zdefiniuj problem, a dopiero potem poszukaj 
technologii, przy pomocy której najłatwiej ów problem da się rozwiązać.

Mnożenie technologii prowadzi tylko do komplikowania prostych systemów. 
Powstają wtedy "systemy dla wierzących" w stylu: "na początku ten system 
ogarniał Bóg i ja, a po pewnym czasie ten system rozumiał już tylko Bóg".

Dlatego moja propozycja: zredukuj stosowane technologie do niezbędnego 
minimum. W przeciwnym wypadku staniesz w pewnym momencie przed ścianą i 
... zaczniesz pisać aplikację od nowa.


>Na pewno chciałem skorzystać ze Spring MVC,

MVC muisze mieć w głowie. Jeśli rozumiesz MVC to bez trudu zrobisz 
aplikacje MVC w JSF (+ rozszerzenia). A jeżeli nie rozumiesz MVC to 
żaden framework nie stworzy za ciebie aplikacji MVC.

Pozdrawiam,
Wojtek

OK, więc co proponujesz ? Sam już zdążyłem zaobserwować, że Spring MVC i JSF to nie jest połączenie z tych 'fits like a glove'. Da się to zrobić bo nawet jest oficjalnie wypuszczona aplikacja Spring Web Flow + JSF/PrimeFaces i to działa - chociaż niestety z pewnymi ograniczeniami (brak możliwości zdefiniowania URL dla h:form jest dość kłopotliwe, jeżeli nie chcemy korzystać za każdym razem z wywołań AJAX w PrimeFaces).
Jestem w trudnej sytuacja, bo do 30 wrześnie muszę złożyć pracę a chciałbym mieć co pokazać jeżeli chodzi o projekt. Więc albo teraz ruszę dalej z tym co mam i jakoś to zepnę, albo szybko znajdę alternatywę, które nie będzie mnie zmuszała to porzucenia kompletnie wszystkiego co mam i zaczęcia od nowa. Nie mam po prostu dość czasu. 

Wojtek - całkiem możliwe, że masz rację, ale na pewno operujesz na wyższym poziomie abstrakcji niż ja i dysponujesz większą wiedzą i doświadczeniem więc możesz tak pisać, bo rozumiesz jak to działa i jesteś w stanie sam napisać pewnie rozwiązania dla własnych potrzeb - ja nie. I jeszcze długo, długo nie.

W dniu 2012-08-15 23:52, kaszpiro pisze:
> OK, więc co proponujesz ?

Proponuję JSF(+rozszerzenia - ja lubię RichFaces ale to rzecz gustu) na 
początek. Zapominamy o Javascrptach, czy AJAKSIE dłubanym w Javascrypcie 
- od tego mamy JSF.
Do JSF2 dorzucamy Facelets. Strony w XHTML. Oczywiście CSS (ale na 
początku to bym nie grzebał stylach - używałbym defaultowe z biblioteki 
rozszerzającej JSF).
Ja bym to tak robił.

Dostęp do bazy - ja lubię JDBC (ewentualnie Springowa obudowa JDBC - 
Spring JDBC Template czy jakoś tak).
Jak się narodzi jakiś problem - będziemy się później martwić.
Im prostsza technologia tym szybciej ruszysz z tematem.

Pozdrawiam,
Wojtek

Hmm, ja nie pisałem, że grzebię sam w JavaScripcie przy moim projekcie. JSF się tym zajmuje a obsługa AJAX-a jest przecież domyślnie wbudowana w JSF2 (bo takiej właśnie wersji będę używał). Musze rzucić jeszcze raz okiem na Tutorial JEE 6, bo tam pewnie znajdę sporo informacji, które będą mi potrzebne żeby dalej działać.

> Im prostsza technologia tym szybciej ruszysz z tematem. 

Tak, ale im prostsza technologia tym więcej kłopotów z rozwiązaniem bardziej złożonych problemów. Ogólnie to trudno mi się połapać co jest co w ekosystemie JEE. Jak dla mnie to za dużo tego jest, masa ludzi próbuje własnych kombinacji i tworzy nowe "frameworki", pluginy, nakładki itp, które strasznie mieszają tym, którzy próbują się z JEE zaznajowmić i zaprzyjaźnić. To jest ogromny problem Javy, niestety tak właśnie jest z oprogramowaniem Open Source - każdy chce to zrobić po swojemu i wychodzi ogromne śmietnisko, na którym można znaleźć całkiem fajne rzeczy, ale pośród nich i mnóstwo zachwalanego dziadostwa. No i jak tu zebrać jakiś "stos" technologii, które akurat spełnią wymagania projektu i będą ze sobą kompatybilne (pisząc kompatybilne mam na myśli 100% kompatybilne, a nie doklejone w jakiś prymitywny sposób tak, żeby tylko się pochwalić, że oto produkt A współpracuje z produktem B). Tak jak Spring + JSF, które niby ze sobą można połączyć, ale jest to połączenie nienaturalne i tak też działa. Dziwi mnie, że Spring wciąż stawia na JSP jako podstawową technologię widoków w swoim modelu MVC.

Jeżeli chodzi o połączenie z bazą to chcę zminimalizować ilość pisania swojego kodu do obsługi połączenia, zarządzania transakcjami i pisania własnych zapytań. Aspekty wydajnościowe nie mają dla mnie w tym momencie żadnego znaczenia. Najlepiej jakiś ORM + wygenerowane klasy Encji (ja korzystam akurat z NetBeans i  korzystam z generatora klas encji na podstawie schematu bazy danych i to mi pasuje) + warstwa service (operacje na klasach encji). Nie wiem czy to właściwe podejście w tym przypadku. Ogólnie brakuje mi jeszcze wiedzy, żeby zdecydować z czego korzystać a z czego nie. Przerabiam przykładowe aplikacje, tutoriale i posiłkuje się dokumentacją, ale to trwa koszmarnie długo, bo są tysiące stron do przestudiowania, żeby czegokolwiek się dowiedzieć. Z PHP nie było tak trudno a też można było co nieco za jego pomocą zbudować.

Generalnie jestem teraz w czarnej d... i nie wiem co dalej zrobić. Za mało dałem sobie czasu na projekt, który mi się wymyślił :) Tak czy siak po obronie pracy będę chciał dalej się wkręcać w JEE, ale już nie tak intensywnie jak teraz (kilkadziesiąt godzin w tygodniu). Jest jakaś sprawdzona ścieżka rozwoju, która powinno się teraz podążać ? Tylko nie mówcie, że powinienem zacząć od notatnika i JSP i servletów, bo wtedy do 50-tki nie zdążę dojść do najnowszych rozwiązań w tej dziedzinie. 
Trochę się rozpisałem i wylałem swoje żale, ale może właśnie trzeba dawać sygnały społeczności Javy z jakimi problemami muszą zmagać się początkujący adepci.

W dniu 2012-08-17 13:41, kaszpiro pisze:
>> Im prostsza technologia tym szybciej ruszysz z tematem.
>
> Tak, ale im prostsza technologia tym więcej kłopotów z rozwiązaniem bardziej złożonych problemów.

A myślisz, że jak będzie złożona, trudna w użyciu technologia - to wtedy 
będzie łatwiej? Mylny błąd :)

> Ogólnie to trudno mi się połapać co jest co w ekosystemie JEE.

To prawda, że wielość technologii jest tu utrudnieniem, bo łatwo można 
pobłądzić. Ale z drugiej strony wielość technologii, to też więcej 
możliwości na rozwiązanie problemów. Tylko że zanim będziemy rozwiązywać 
problem przy pomocy jakiejś technologii - to najpierw niech się ten 
problem pojawi (mówiłem o tym wcześniej).


> Jeżeli chodzi o połączenie z bazą to chcę zminimalizować ilość pisania swojego kodu do obsługi połączenia, zarządzania transakcjami i pisania własnych zapytań.

I ja dlatego stosuje JDBC :) Oczywiście to że ja to stosuje nie znaczy, 
że każdy ma też tak postępować. Pamiętaj, że nie ma jednej najlepszej 
technologii. Wybór technologii zależy też od wiedzy, doświadczenia 
zespołu. W Twoim przypadku - to zależy od tego, w czym się dobrze 
czujesz. Jeżeli lepiej się czujesz w Hibernate/JPA - to stosuj to.

> Generalnie jestem teraz w czarnej d... i nie wiem co dalej zrobić. Za mało dałem sobie czasu na projekt, który mi się wymyślił :)

Nie jestem tego pewien, że masz za mało czasu.
Przecież w JSF+Twoja obsługa bazy naprawdę można dużo napisać i szybko 
zacząć.
Więc zacznij pisać kod. Daj se spokój z problemami typu: jak technologię 
X połaczyć z technologią Y - o ile obecnie nie masz potrzeby łączenia 
tych technologii. To do niczego nie prowadzi.

Ja bym dodatkowo stosował architekturę MVC - tzn. na bazie MVC 
rozbudował bym warstwy aplikacji, tak by logikę odseparować od 
technologii widoku oraz od technologii bazy. Ale to też moje podejście - 
nie każdy musi się z tym zgadzać.

Pozdrawiam,
Wojtek

> Ja bym dodatkowo stosował architekturę MVC - tzn. na bazie MVC 
> 
> rozbudował bym warstwy aplikacji, tak by logikę odseparować od 
> 
> technologii widoku oraz od technologii bazy. Ale to też moje podejście - 
> 
> nie każdy musi się z tym zgadzać.

Witaj,

z tym się oczywiście zgadzam. Nie chcę tworzyć potworków, które będą później praktycznie niemożliwe do utrzymania i rozbudowywania. Model MVC już stosowałem w PHP i jestem jego zwolennikiem, bo to jedyny słuszny sposób zapanowania nad rozrastającą się aplikacją. Rozumiem, że powinienem skłaniać się ku wykorzystaniu technologii ujętych w specyfikacji Java 6EE (Servlety + adnotacje, JSF2 + np. PrimeFaces, JPA2) i to na początek wystarczy ?
Więc spróbujmy rozłożyć to na czynniki pierwsze:
- View - JSF2 + PrimeFaces
- Model - Encje + Backing Beans ?
- Controller - Servlety ?

Jako serwera używam GlassFisha (v. 3.1.2) dołączonego do NetBeansa (v. 7.1.2) i generalnie jestem zadowolony. Lepszym wyjściem będzie Tomcat czy nie ma to większego znaczenia ?

W dniu 2012-08-18 13:00, kaszpiro pisze:

> z tym się oczywiście zgadzam. Nie chcę tworzyć potworków, które będą później praktycznie niemożliwe do utrzymania i rozbudowywania. Model MVC już stosowałem w PHP i jestem jego zwolennikiem, bo to jedyny słuszny sposób zapanowania nad rozrastającą się aplikacją. Rozumiem, że powinienem skłaniać się ku wykorzystaniu technologii ujętych w specyfikacji Java 6EE (Servlety + adnotacje, JSF2 + np. PrimeFaces, JPA2) i to na początek wystarczy ?
> Więc spróbujmy rozłożyć to na czynniki pierwsze:
> - View - JSF2 + PrimeFaces
> - Model - Encje + Backing Beans ?
> - Controller - Servlety ?

Controller - Managed Bean lub CDI.
Ja serwlety w aplikacjach JSF+RichFaces używałem tylko do jakichś 
specyficznych celów (np. generowania wykresów - choć zdaje się, że 
PrimeFaces ma tag obsługujący wykresy).


>
> Jako serwera używam GlassFisha (v. 3.1.2) dołączonego do NetBeansa (v. 7.1.2) i generalnie jestem zadowolony. Lepszym wyjściem będzie Tomcat czy nie ma to większego znaczenia ?
>

Zostań przy GlassFishu. Tomcat kiedyś był kontenerem serwletów. Czy jest 
dzisiaj serwerem aplikacji - nie wiem.

W każdym bądź razie możesz śmiało zacząć aplikację przy pomocy w/w 
bibliotek, narzędzi. Nowe technologie dodawaj tylko, gdy pojawi się 
jakiś problem, którego nie możesz rozwiązać przy pomocy dotychczasowej 
technologii.

Pozdrawiam,
Wojtek