Użyteczność JSF

0

Cześć,

Generalnie jestem fanem Javy. Programowałem w JSE (SWING, NET), RIA(EJB+JWS), JavaFX i wszystko ładnie chodziło.
Teraz mam drugie czy trzecie podejście do JSF na GlassFish no i po raz kolejny masakra.
A mianowicie mam na myśli, że parę rzeczy nie chodzi zgodnie ze specyfikacją, albo niestabilnie. Dodatkowo znajduję o tych problemach info w sieci sprzed np. 3-4 lat i...
i nic, bugi nadal są, czyli nikomu nie przeszkadzają, że nie zostały naprawione? czy może po prostu nikt tego nie używa do poważnych zastosowań? Pojawia się w końcu pytanie: Czy ktoś z Was używał JSF choćby w średniej wielkości aplikacji? Bo ja właśnie się zastanawiam się czy się nie przenieść na inny framework i nie wywalić w błoto dotychczas zainwestowanego czasu w aplikację (na szczęście tylko tydzień pracy).

0

Ja uzywalem, nie warto sie meczyc, przenies sie na cos innego. Za moich czasow (rok temu) modny byl np. Wicket.

0

Powiedz proszę co tak zraziło Cię w JSF. Ja dość dużo pisałem w JSF (najpierw 1.2 i IceFaces, potem projekt zmigrowany do JSF 2.x i IceFaces compat) oraz sporo w 2.2 z PrimeFaces.

Nie takie małe projekty, jeden z nich na ponad 80k linii kodu samej Javy. Moim zdaniem pisanie w JSF jest banalnie proste, jednak krzywa uczenia jest dość długa w stosunku do innych technologii: po prostu framework ten ma dość dużo opcji, jak np. niezależy @ViewScoped w każdej zakładce, czego bardzo brakuje w ASP.NET.

Nie rozumiem w czym wicket jest lepszy od np. gołego JSF 2.2 i facelets: w tym momencie też mogę sobie dobrać customowe frameworki JavaScript i tworzyć własne komponenty jeśli mam na to umiejętności, czas i budżet.

2

Ciekawy artykuł:
http://blog.brunoborges.com.b[...]why-im-reconsidering-jsf.html

Powiem dlaczego lubię JSF:

  1. Integracja z EJB3 out-of-box.
  2. Banalna integracja ze Spring Security (również przy CDI).
  3. PrimeFaces: dużo gotowych komponentów mocno wykorzystujących możliwości klienta.
  4. Dodatki jak np. OmniFaces pozwalające na ograniczenie JSF boilerplate jak np. wołanie do kontekstu. Do tego mnóstwo converterów.
  5. W przypadku starego, praktycznego przemysłowego projektu migrowałem IceFaces 1.8 do JSF 2.2 po zmianie JEE5 na JEE7 i wszystko działa (IceFaces, dla odmiany bardziej server-side odmiana JSF z AJAX push). Działa, rónież na CDI.
  6. Łatwość tworzenia nowych komponentów w JSF2.
  7. Jeśli chcę zbudować otwartą aplikację webowa z bookmarkable RESTful URL to się da: mogę wykorzystać PrettyFaces.
  8. Świetne wsparcie IDE.
  9. Dużo ofert pracy.
  10. Banalne tworzenie szablonów z facelets, nie to co kiedyś z JSF 1.2/ JSP (JSF 1.2 z facelet + IceFaces jest już spoko).
  11. Duża społeczność skupiona np. wokół PrimeFaces.

Wady:

  1. Dobre pół roku zajęło mi nabranie przemysłowej sprawności w JSF (łącznie z nauką, migracjami JSF 1.2, JSF 2.2 itp.).
  2. Po roku uważam, że jeszcze muszę sporo się nauczyć: jest to bardziej rozbudowane niż np. Spring MVC (ale tam nauka jest zrzucona na frameworki jak extJS czy Dojo, w praktyce moim zdaniem może trwać dłużej).
  3. Dużo pojęć: można się pogubić kiedy używać JSF Managed Beans, a kiedy CDI (do tego dochodzą zagadnienia czy mamy serwer aplikacji, czy kontener serveletow, czy integrujemy ze springiem czy jee).
  4. Nie widzę realnego ograniczenia dlaczego JSF miało by słabo się nadawać na moją nową aplikację.
  5. Istnieje dużo różnych odmian (ADF, vanilla, RichFaces, PrimeFaces, IceFaces), implementacji (Mojarra, IceFaces), co utrudnia wejście w temat.

Tak naprawdę nie zamierzam uczyć się nowych frameworków webowych, a skupić się na poznaniu jQuery, CSS, HTML5 i tworzeniu własnych komponentów dla JSF. Jako realną alternatywę wartą poznania uważam AngularJS dla zupełnie innego typu aplikacji, z którymi komunikował się będę za pomocą REST (tworząc np. transakcyjny backend w EJB) i to zamierzam zainwestować swój czas w przyszłości obok dalszej nauki JSF.

0

Napisałem:

implementacji (Mojarra, IceFaces)
miałem na myśli (Mojarra, MyFaces).
http://myfaces.apache.org/

0
mk761203 napisał(a):

(...) Czy ktoś z Was używał JSF choćby w średniej wielkości aplikacji?

Firma, w której byłem - tak.

Do głównych zalet JSF należy dodać, że ten framework wchodzi w skład standardu JEE.

1

Aktualnie w firmie mamy średniej wielkości aplikację w JSF + primeface i muszę przyznać, że nie ma tragedii....
Oczywiście jak klient sobie życzy aby np w tabelce była możliwość sortowania po wielu kolumnach a np primefaces nie daje takich możliwości to to jest wtedy dramat
Oczywiście graficy rwą włosy z głowy aby to wystylować....ale dają rade.

Jak coś moge podać linka na priv do aplikacji

Dla mnie najlepszy zestaw to
Spring MVC + Freemearker +Bootstrap
lub Spring Rest + AngularJS + Bootstrap
lub Play Framowrk + AngularJS + Bootstrap

Żadnych scopów, powalonych cyklów życia, VIewExpiredException, wielokrotnych wołania geterów z modelu ..ble

0

@Szczery:

  1. Jakiej wersji PrimeFaces używacie?
  2. Integrujecie z JEE czy ze Springiem?
  3. Co do AngularJS, skąd bieżecie gotowe komponenty? Jak będę miał chwilę chcę sobie zbudować proof-of-concept i tak zastanawiam się czy jest coś gotowego porównywalnego do:
    http://www.primefaces.org/showcase/
    Spodziewam się raczej drobnych elementów w stylu jQueryUI.
  4. Jak zabezpiecza się aplikacje AngularJS (w moim proof-of-concept chcę postawić na SSL + basic authentication)?
0

1) Primefaces 3.4.x
2) GUI: JSF + CDI, Biznes: Spring
3) AngularUI + NgGrid + Bootstrap
4) Dokładnie jak piszesz. Dokładasz do anuglara interceptor http/https który jaki widzi ze kod błędu to 401 to pokazuje strone logowania

0

Ad 2. A więc się da. Kiedyś muszę spróbować takiej konfigurajcji. Zwłaszcza, że w planach mam pisanie aplikacji proof-of-concept, aby pobieżnie zapoznać się z możliwościami Hadoop, a z tego co widzę Spring-Data to ładnie wspiera.
Zastanawiam się jeszcze nad wariantem TomEE, gdyż tam podobno łatwo rozwiązali integracje Spring -> OpenEJB, ale jeszcze nie testowałem.

Co do JSF Scopes: jak zaczynałem pracę miałem z tym straszny problem i często źle ich używałem. Jednak w tej chwili uważam, że to bardzo wygodny mechanizm, zwłaszcza że to tak naprawdę nakładka na standardowe scopes dostępne w Servletach. Do tego możliwość łatwego dependency injection pozwala na pisanie bardzo ładnego, modułowego kodu, zgodnie z zasadą pojedynczej odpowiedzialności. Zarządzanie sesją jest łatwe: jak trzeba można usunąć z niej co trzeba. I tak sesji używa się raczej rzadko, najczęściej wykorzystuje się @ViewScoped. Flash też jest dostępny, jak trzeba np. przekazać obiekt między dwoma redirectami i dostęp do niego jest banalny (Faces.getFlash()). Z reguły mam tak, że dla bardzo skomplikowanego widoku mam np. 10 różnych Managed Beans i każdy zajmuje się innym przypadkiem użycia (np. jak jest skomplikowany widok). Kod jest elegancki, modułowy, łatwy w utrzymaniu. Ale początki były trudne.

Co do stylizowania, przerabiałem to z IceFace 1.8, które wygląda obrzydliwie. To się spokojnie da zrobić, wystarczy potworzyć odpowiednie klasy CSS i mieć osobę, która potrafi to robić. Jeśli style to za mało da się podłączyć jQuery i zbudować customową funkcjonalność. W PrimeFaces jest już dużo łatwiej: jQuery jest dostępne out-of-box, a pisanie logiki walidacji, nawet zgodnej z BeanValidation po stronie klienta jest łatwe.

W tej chwili jest już PrimeFaces 5.0, a całość rozwija się bardzo dynamicznie: wciąż dodają nowe opcje i dopracowywują stare.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0