Postaw sobie aplikacje webową. Fajny starter

Cześć.
Znalazłam fajną rzecz dla programistów Java, którzy chcą szybko postawić webaplikacje
a nie lubią babrać się z konfiguracją frontendu. Projekt, który z marszu integruje
Spring Boota / PrimeFaces / BootsFaces / OmniFaces / AngularFaces / Mojarra / MyFaces i
jeden z trzech serwerków Tomcat / Jetty / Undertow. (｡◕‿‿◕｡)

https://github.com/joinfaces/joinfaces

tutaj przykład aplikacji:
https://github.com/joinfaces/joinfaces-example

tutaj wiki projektu:
https://github.com/joinfaces/joinfaces/wiki

dostępnych jest wiele startowych zestawów jak np. (! uwaga):
jsf-jetty-myfaces-bootsfaces-spring-boot-starter:
https://github.com/joinfaces/joinfaces/wiki/JSF-Spring-Boot-Starters

możliwości bootsfaces:
http://showcase.bootsfaces.net/forms/inputText.jsf

możliwości primefaces:
http://www.primefaces.org/showcase/

wszystko pakowane do jednego spring bootowego jara.
Polecam.

A tak z ciekawości, jak często używa sie teraz PrimeFaces i podobnych?

shagrin napisał(a):

A tak z ciekawości, jak często używa sie teraz PrimeFaces i podobnych?

W Niemczech bardzo duzo - jakies maja zamilowanie do zombie technologii. W kazdym razie szczerze odradzam wprowadzanie JSF we wlasnych projektach.

@jarekr000000 dlaczego i co proponujesz w zamian? Coś łatwego do ogarnięcia przez przeciętnego java kodziarza i równie dobrego jak PrimeFaces.
Z wieloma gotowymi i działającymi komponentami tak jak w PrimeFaces

karolinaa napisał(a):

@jarekr000000 dlaczego i co proponujesz w zamian? Coś łatwego do ogarnięcia przez przeciętnego java kodziarza i równie dobrego jak PrimeFaces.
Z wieloma gotowymi i działającymi komponentami tak jak w PrimeFaces

JSF i PrimeFaces zupenie nie jest proste i latwe do ogarniecia.
Przed wszystkim wszyscy gina na cyklu zycia beanow (session, viewscope). Trzeba duzo przeczytac i pocwiczyc zeby to ogarnac. Samemu sie nawet da - ale w zespole praktycznie zawsze znajdzie sie kilku, ktorzy nie doczytaja i sie robi bryndza. Jak sie to zawali - to juz potem ciezko odkrecic.

Przede wszystkim niepotrzebne - w javie latwo mozna wystawic Restowe API i robic front jako single page
w Angular2 (typescript) lub Angular1 (JS). proste, latwe, debugowalne ,testowalne i przecietny koder latwiej to ogarnia (mniej magii). Modulow gotowych mnostwo!

JSF generalnie nie byl zaprojektowany do robienia Single Page Applications, a nawet Ajax - i to niestety widac. (See wszystkie fazy .... renderowania strony (WTF - jak to sie ma do roku 2016?)).

Btw. w duzych aplikacjach JSF pojawiaja sie duze problem z wydajnoscia (zajetosc pamieci glownie) ,zwykle fallback to przepisywanie niektorych stron na JavaScript i Rest. A mieszanie JSF z JS to juz pelnia katastrofy.
Lepiej sobie oszczedzic.

Poniewaz, JavaScript jest oczywiscie tragiczny - to zdecydowanie Typescript.
Chociaz TS tez idealny nie jest to jeszcze sa dwa rozwiazania:

1. https://www.scala-js.org/ - super jestem bardzo zadowolony, ale trzeba byc scalowcem
2. http://www.jsweet.org/ - ciekawostka - java to JS transpiler. Moim zdaniem dla zatwardzialych javowcow - warto sprobowac. (Chociaz nic nie moge powiedziec o jakosci tego projektu - hello world dziala).

Rekomenduje PrimeFaces do nowych projektów, gdzie skalowalność aplikacji nie ma krytycznego znaczenia, ViewScoped to jest jednak stanowe podejście do wytwarzania aplikacji, które ma pewne zalety (i wiele wad też).

@ViewScoped nie jest trudne, wystarczy wiedzieć, że:

• to wycinek SessionScoped
• na jedną kartę przeglądarki przepada 1 ViewScoped
• stan pomiędzy kartami przeglądarek dla tego samego widoku nie jest współdzielony
• jak robimy redirect stan @ViewScoped umiera (również za pomoca nawigacji JSF), przy page forward nie

Po pół roku pisania w PrimeFaces można ekstremalnie szybko pisać przyzwoite aplikacje.

Mam zamiar nauczyć się Angular 2 + BootStrap i zobaczyć różnicę, wypróbuje też pewnie PrimeNG.

@karolinaa:

• czy projekt, który rekomendujesz wykorzystuje jednocześnie CDI i Springa?
• czy nie lepiej użyć po prostu serwera aplikacyjnego, co takiego daje tutaj Spring Boot (z tego co widzę integracja ze Spring Security to może być fajna wartość dodana)?
• mam wątpliwość, czy to będzie działać w pełni jeśli chodzi o CDI, ale chętnie przejrzę: w szczególności ciekawi mnie czy obsługiwane są nowości dodane w JSF 2.2 (np. CDI) @FlowScoped

Testowałem konfigurację Spring Boot + JSF z JSF Managed Beans ViewScoped przeportowanym jako springowy custom scope i działa, ale trzeba mieć co najmniej Tomcat 8 dla JSF 2.2+. Chyba wolę wziąć serwer aplikacyjny bo jest prościej (może WildFly Swarm?). Serwer aplikacyjny wydaje mi się bezpieczniejszym rozwiązaniem, bo jest mniejsze prawdopodobieństwo leaka.

PrimeFaces się bardzo fajnie rozwija np. w 6.0 dodali siatkę w stylu bootstrapa. Poza tym to sensowna ścieżka migracji dla legacy aplikacji pisanych od wielu lat np. w IceFaces (mam na głowie system w IceFaces 3.3 kompatybilne z 1.8 portowane jeszcze kiedyś na JSF 2.2 w ramach życia legacy projektu).

Co do uzytecznosci roznych frameworkow GUI itp polecam tzw. kryterium Ponga.
W roku 1975 na Atari (8bit) zaimplementowano gre Pong: https://en.wikipedia.org/wiki/Pong

I teraz pytanie czy w twoim framework UI dasz rade to zrobic? - czy cos Ci ten framework pomoze?
Bo jesli nie - to ten framework nie jest gotowy nawet na rok 1975,
a co dopiero na 2016.

Btw. siedze w plikacjach biznesowych, jest rok 2016 i klientom nie wystarcza juz statyczne GUI
z prostym bijacym po oczach CRUDEm.

Jeśli chce się robić skomplikowane frontendy i dać pełną swobodę frontend deweloperowi JSF nie jest najlepszym rozwiązaniem: nie zastanawiałbym się długo tylko wystawił REST API. Jeśli aplikacja wymaga ostrego hakowania styli to PrimeFaces nie jest rozwiązaniem.

Co do ponga, na pewno nie byłoby problemów: jest HTML 5 Canvas, jest jQuery, nic więcej nie potrzeba (wszystko w standardzie PF).

Jeśli rozważa się użycie full stack developerów, czyli ludzie mają pisać i Java i GUI to w przypadku aplikacji wewnętrznych PF to IMO opcja warta rozważenia, może być szybciej niż wystawiać API restowe, jeśli piszemy aplikacje z dużą liczbą tabelek. Wszystko zależy od wymagań. Do systemu finansowo-księgowego PF jest spoko.

Byłem dzisiaj na małym workshopie na temat technologii web w moim departamencie, podyskutować w czym różne projekty są klepane i jakie są plusy/minusy i generalnie konkluzja była taka że generalnie u nas na topie jest Spring (+Boot), Angular (1.5/2), TypeScript, NodeJS ;)

@Shalom jeszcze niedawno mówiłeś, że SPA to shit jak trzeba zaprogramować, więcej niż 5 przycisków na krzyż z skomplikowaną logiką na formatce XD :P

Dobra w takim razie zmieniam target i zacznę się uczyć Angulara. Tylko, że tam wszystko jest tak nakućkane, szybko się zmienia i wgle że głowa boli.
jakieś webpacki, jakieś dziwne rzeczy. trudne to wszystko w porównaniu z zwykłymi primefacesami.
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.26b3owhbp

zresztą jestem zdania, że przeciętnemu java developerowi znacznie łatwiej i szybciej ogarnąć
JSFy aniżeli TP, Angular'a i ten cały modern HTML5 obecny current frontend

margor90 napisał(a):

Rekomenduje PrimeFaces do nowych projektów, gdzie skalowalność aplikacji nie ma krytycznego znaczenia

przecież można postawić kilkanaście instacji, przed nimi nginxa a na tomcacie współdzielenie sesji. co tu się nie skaluje o.0 ? ;)

jarekr000000 napisał(a):

JSF generalnie nie byl zaprojektowany do robienia Single Page Applications, a nawet Ajax - i to niestety widac. (See wszystkie fazy .... renderowania strony (WTF - jak to sie ma do roku 2016?)).

no taa, ale też się da niby SPA robić:
pacz: http://showcase.bootsfaces.net/layout/navigationAndAJAX.jsf;jsessionid=Ljfre_URHO3V2tMHJa6g_vPU5p9bCfZJtR5rTk29.wildfly01

tylko najlepiej używać apache myfaces http://stackoverflow.com/a/7113961

Ja się totalnie wymiksowałem z weba i frontu, ktoś orientuje się jaki jest status Polymera?

przecież można postawić kilkanaście instacji, przed nimi nginxa a na tomcacie współdzielenie sesji. co tu się nie skaluje o.0 ? ;)

Jak coś nie ma stanu, to może być obsłużone przez dowolnego klienta. Wywołanie stanowe (sesyjne) nie będzie się skalowało, bo jest zależne od konkretnej sesji klienta (niezależnie od liczby węzłów). Oczywiście są work-a-roundy np. Hazelcast (klastrowanie sesji), ale nie wnikałem jak to działa wewnętrznie pewnie jakaś replikacja.

karolinaa napisał(a):

@
zresztą jestem zdania, że przeciętnemu java developerowi znacznie łatwiej i szybciej ogarnąć
JSFy aniżeli TP, Angular'a i ten cały modern HTML5 obecny current frontend

Ja sie z tym nie zgadzam - widzialem praktycznie tylko porazki. Glownie na wspomnianym nie zrozumieniu cyklu zycia beanow i faz renderowania JSF.
Latwiej mi sie bylo (rok 2012 ) wyniesc z JSF i nauczyc calego HTML5 , JS, CSS od nowa niz ciagle poprawiac wpierniczane na potege SessionScopy :-).

Nie mowiac o wygladzie aplikacji. Primefaces wyglada dobrze tylko do czasu jak klient nie zapragnie dostosowac kolorow do swojego jedynie slusznego Korpostylu :-)

Strona zrobiona w PrimeFaces:
http://www.tipi.camp

Ja to najbardziej nie lubię jak ktoś robi single-page-application z multi-page-application, czyli takie wciskanie SPA na siłę tam gdzie aplikacja w gruncie rzeczy jest wielo-stronowa

margor90 napisał(a):

Strona zrobiona w PrimeFaces:
http://www.tipi.camp

Ta może nie Primefaces ale JSF:
http://www.gameduell.com

JSyF i PrimitiveFaces należało by już dawno wypalić do gołej ziemi, zasypać metrową warstwą soli i całość zatopić w odpadach z produkcji plutonu.

1. Cykle życia beanów są pomyślane o webie z roku 1995. Ładujemy całą stronę i z całą stroną pracujemy.
2. Tragiczna wręcz integracja z rozwiązaniami dynamicznymi (np. wykresami live, streamingiem danych, websocketami). Zazwyczaj kończy się pisaniem kontrolki, która pod spodem uderza do jakiegoś restowego API ma w rejestrze DUPIX cały syf głównej aplikacji.
3. Zapomnijmy o SPA w kontekście JSF/PF... chyba że czujemy potrzebę pisania w HTMLu 3.2 i nadużywania iFrame/Frame.
4. Pamięciożerność i co za tym idzie skalowalność. Niestety rozwiązania w rodzaju klaster tomcatów ze współdzieloną sesją nie jest fajnym rozwiązaniem w roku 2016.
5. Mieszanie front i backendu. Generalnie lubię rozwiązania typu Vaadin, gdzie piszę w Javie, a wyświetla się w HTMLu, ale to jest dobre jedynie w przypadku gdy brakuje nam frontendowców/grafików/webowców by aplikacja wyglądała do ludzi. Jednak to jak powinno być renderowane i magia biznesowa powinny być oddzielone na poziomie technologii i gadać ze sobą po protokołach w rodzaju HTTP czy protobuf. JSF miesza rzeczy backendowe z frontendowymi. Nawet jak uda się to jakoś odseparować, to w większym zespole znajdzie się jakiś nowy, który tego nie ogarnie albo zajdzie zmiana, która nam zaorze separację (bo coś tam).

Co osobiście?

1. Vaadin jak robimy SPA i nie znamy się na JS i HTML+CSS na tyle by wyprodukować coś funkcjonalnego i ładnego zarazem.
2. REST framework w rodzaju SpringBoot+REST, Spray.io, Wasabi, Akka HTTP i przód zrobiony w Angularze/Emberze/NodeJS+Jade(albo Mustache albo czymś w ten deseń). Mamy wtedy możliwość fizycznej separacji backendu i artystów.

Nie mam osobistego doświadczenia z JSP, ale koledzy "dinozaury" mówią, żeby uciekać od tego jak najdalej.

Zimny Terrorysta napisał(a):

Nie mam osobistego doświadczenia z JSP, ale koledzy "dinozaury" mówią, żeby uciekać od tego jak najdalej.

jeszcze zatęsknią

Koziołek napisał(a):

1. Tragiczna wręcz integracja z rozwiązaniami dynamicznymi (np. wykresami live, streamingiem danych, websocketami). Zazwyczaj kończy się pisaniem kontrolki, która pod spodem uderza do jakiegoś restowego API ma w rejestrze DUPIX cały syf głównej aplikacji.

JSF 2.3 ma zawierać bardzo prostą integrację z WebSocketami. Uderzenie do REST api, którego nie używa się tak często to zwykłe jQuery AJAX w standardzie PrimeFaces.

Koziołek napisał(a):

1. Zapomnijmy o SPA w kontekście JSF/PF... chyba że czujemy potrzebę pisania w HTMLu 3.2 i nadużywania iFrame/Frame.

Bez przesady, można używać elganckiej HTML 5 friendly markup. Nie lubię SPA w JSF i nie używam są do tego lepsze technologie. Po prostu słabo się pisze. Co innego aplikacje, gdzie używa się redirect: przynajmniej wiadomo kiedy @ViewScoped kończy życie.

Koziołek napisał(a):

1. Pamięciożerność i co za tym idzie skalowalność. Niestety rozwiązania w rodzaju klaster tomcatów ze współdzieloną sesją nie jest fajnym rozwiązaniem w roku 2016.

Zgoda, ale Vaadin ma dokładnie ten sam problem tylko na większą skalę: PrimeFaces ostro używa client-side (jQuery). Już wolę pisać desktop niż Vaadin (i konsumować REST) lub użyć jakiegoś Angulara 2 (NativeScript?).

@margor90, ja nie mówię, że Vaadin jest wspaniały i jedyny słuszny. On jest OK, jak nie masz frontendowców pod ręką. Rzecz w tym, że na chwilę obecną JSF jest bardzo ograniczoną technologią jeżeli chcemy pisać aplikacje z interfejsem webowym. Co innego portaloza, ale to już zupełnie inna bajka.