Qual è la necessità di JSF, quando l'interfaccia utente può essere ottenuta con librerie JavaScript come jQuery e AngularJS

116

Stavo leggendo di JSF che è un framework dell'interfaccia utente e fornisce alcuni componenti dell'interfaccia utente. Ma in che modo è migliore o diverso dal numero di componenti disponibili da jQueryUI, AngularJS, ExtJS o anche HTML, CSS e JavaScript.

Perché qualcuno dovrebbe imparare JSF?

user-interface jsf javascript-framework

— sushil bharwani
fonte

3

vantaggi dell'html generato dal server: ricerca nei motori di ricerca, visualizzazione nascosta in base all'autorizzazione. altrimenti, l'abbiamo abbandonato per pura interfaccia utente ajax.

— Neil McGuigan

5

Ho anche abbandonato JSF a favore di AngularJS + RESTful backend. (Mele e arance, ma Angular è così carino che non ho bisogno di molti dei vantaggi di JSF)

— arg20

JSF è un framework MVC basato su componenti che è costruito sopra l'API Servlet e fornisce componenti tramite taglib che possono essere utilizzati in JSP o qualsiasi altra tecnologia di visualizzazione basata su Java come Facelets.

— Divyesh Kanzariya

154

Da JSF a semplice JSP / Servlet / HTML / CSS / JS è come jQuery a semplice JS: fai di più con meno codice. Per prendere PrimeFaces (basato su jQuery + jQuery UI) come esempio, sfoglia la sua vetrina per vedere esempi di codice completi. BootsFaces ( basato su jQuery + Bootstrap UI) ha anche una vetrina con esempi di codice completi. Se studi attentamente questi esempi, vedrai che fondamentalmente hai bisogno di una semplice classe Javabean come modello e di un file XHTML come vista.

Nota che non dovresti vedere JSF come sostituto del solo HTML / CSS / JS, dovresti anche prendere in considerazione la parte lato server (in particolare: JSP / Servlet). JSF elimina la necessità di tutto il boilerplate di raccogliere i parametri di richiesta HTTP, convertirli / convalidarli, aggiornare i valori del modello, eseguire il metodo Java corretto per fare le cose di business e generare il codice boilerplate HTML / CSS / JS. Con JSF fondamentalmente si finisce con una pagina XHTML come definizione della vista e una classe Javabean come definizione del modello. Ciò accelera notevolmente lo sviluppo.

Come con ogni framework MVC Web basato su componenti, in JSF hai un controllo meno granulare sull'HTML / CSS / JS renderizzato. L'aggiunta di codice JS personalizzato non è così facile in quanto è necessario tenere in considerazione anche lo stato di visualizzazione JSF sul lato server (ad esempio, abilitare un pulsante disabilitato sul lato JS non abiliterà il pulsante sul lato JSF, che a sua volta è un enorme vantaggio in termini di sicurezza). Se questo è comunque uno dei principali ostacoli, allora cerca piuttosto un framework MVC web basato sull'azione come Spring MVC . Avrete solo prendere in considerazione che si deve scrivere tutto ciò che HTML / CSS / JS codice (e la prevenzione contro XSS, CSRF e DOM-manipolazione!) Da soli . Inoltre, se torni da Facelets a JSP, perderai anche le funzionalità avanzate di template.

D'altra parte, se si dispone di un grande sito Web basato su JSP / Servlet / HTML / CSS / JS / jQuery e si desidera eseguire il refactoring del codice boilerplate JSP / Servlet / HTML / CSS / JS / jQuery ripetuto in componenti riutilizzabili, una delle soluzioni sarebbe JSF. Modelli personalizzati, file di tag e componenti possono aiutare in questo. In questa prospettiva, JSF sta al di sopra di JSP / Servlet / HTML / CSS / JS / jQuery (ed è anche per questo che è piuttosto importante comprendere queste basi prima di immergersi in JSF).

Puoi trovare un progetto basato su JSF di kickoff nel mondo reale qui: Java EE Kickoff App . Vedrai che contiene accanto a JSF come buoni HTML5 , CSS3 e jQuery .

Guarda anche:

— BalusC
fonte

15

Fare di più con meno codice? Ma con più xml ... che compromesso ... inoltre, ti priva di flessibilità

— Danubian Sailor

33

In JSF 2.0+, xml non è necessario.

— Cagatay Civici

5

Abbiamo annotazioni in JSF 2.0

— VdeX

1

Sembra che non ci sia una chiara delineazione tra il livello aziendale / controller e la vista, con JSF, poiché gran parte della vista viene generata sul server. Capisco che tutto viene compilato sul server prima di essere inviato al browser, ma preferisco che il mio oggetto Java restituisca i dati che la vista restituisce, piuttosto che inviare logica / dati di rendering.

— Rick

1

d'accordo JSF è cosa lato server con un potente controllo su HTML.

— Plain_Dude_Sleeping_Alone

28

JSF è stato creato per fare in modo che i negozi Java non dovessero imparare cose come jQuery e costruire JS complessi, ma invece concentrarsi su uno stack puramente Java. In un mondo in cui il tempo è denaro e molti posti si concentrano già sullo sviluppo Java, un linguaggio / pezzo in meno nello stack rende l'addestramento e la manutenzione più veloci e quindi più economici.

Aggiungerò che JavaScript è facile da diventare un incubo di manutenzione per grandi team, soprattutto se alcuni degli sviluppatori del progetto non sono molto esperti di web.

— Andrew White
fonte

Quindi, se sono abbastanza a mio agio con JQuery JS ecc. Non è necessario che mi concentri su JSF?

— sushil bharwani

2

Tutto dipende dal problema che stai cercando di risolvere e con quale squadra lo stai risolvendo.

— Andrew White

1

Sono d'accordo sul team, ma sono interessato a scoprire quali diversi problemi può risolvere JSF e js jQuery ecc. Sto solo cercando di sviluppare la motivazione per imparare JSF.

— sushil bharwani

1

Nessuno, fornisce solo un modo diverso per risolvere gli stessi problemi.

— Andrew White

8

Anche se sei davvero a tuo agio con JQuery, JSF è comunque molto utile. Fornisce un modo semplice per connettere il codice lato server alle rappresentazioni lato client. Alcuni "componenti compositi" di Facelets sono solo un involucro piuttosto sottile attorno a HTML e JS (incluso JQuery). Sono un gioco da ragazzi e in generale semplificano l'intera connessione lato server.

— Arjan Tijms

23

Con Javascript e framework come jQuery hai piena flessibilità e pieno controllo. Con ext ecc perdi molto controllo e devi adattarti al framework. Con JSF perdi totalmente il controllo e devi adattarti totalmente al framework. Vieni invocato in cicli di vita ecc. E infine non hai alcun controllo su quando la chiamata al server può essere effettuata e dove no. Se devi fare qualcosa di considerato "speciale", sei in una posizione molto difficile. E nel mondo JSF anche cose di base come l'ordinamento di tabelle a più colonne oi campi in cui è possibile digitare solo un set limitato di caratteri (come il campo numerico) sono considerati "speciali".

Tuttavia, più flessibilità hai, più errori o cattive pratiche puoi fare. L'elevata flessibilità funziona solo con programmatori altamente intelligenti, altri trasformeranno il progetto in un incubo ingestibile.

Ma, con JSF e la sua flessibilità limitata, c'è sempre solo pochi (o anche solo uno) modo corretto di fare qualcosa. Sei molto limitato, non puoi fare scorciatoie, devi scrivere più XML ecc. - Ma quando ti adatti allo standard, c'è un controllo migliore sul codice che i programmatori inesperti o poco qualificati produrranno. Di conseguenza, le grandi aziende amano JSF perché è "più sicuro" per loro.

Quando sono passato da GWT a JSF, sono rimasto scioccato, quante cose, che mi erano naturali, erano considerate altamente atipiche e quanto le cose semplici fossero così difficili da ottenere. Inoltre, anche le modifiche più piccole, come l'aggiunta del segno ":" dopo l'etichetta, che nell'app GWT / jQuery avrebbe modificato un'etichetta che generava una funzione, richiedeva la modifica di dozzine di file con proprietà localizzate, che non erano nemmeno prese in considerazione da chiunque tranne me strano ...

— Marinaio danese
fonte

7

PrimeFaces è basato su jQuery, quindi hai molta flessibilità sul lato client, inoltre i componenti PrimeFaces forniscono molti hook sul lato client e server come callback di eventi da personalizzare. Le API Javascript possono essere sovrascritte e anche CSS per un aspetto personalizzato. : l'etichetta può essere configurata globalmente in web.xml per un carattere più amichevole con jQuery.

— Cagatay Civici

1

Concordato. La regola generale è: l'utilizzo di alcun framework richiede una programmazione javascript avanzata e sarà difficile da mantenere, ma consente una potenza e una complessità notevolmente maggiori, mentre fare affidamento sui framework sarà più facile da costruire e mantenere, ma limiterà la capacità potenziale dell'app.

— KTys

10

I vantaggi dell'utilizzo di JSF non sono solo nella generazione di xhtml + css + js. A volte JSF impone una restrizione sul markup che puoi generare, come qualsiasi framework basato su componenti. Ma JSF non è solo per questo, il suo stile di vita aiuta enormemente. Dopo aver convalidato l'input, può aggiornare il modello e sincronizzare i bean lato server senza alcuno sforzo. basta dire "qualunque cosa l'utente digiti qui, controlla se è un numero, se sì, memorizzalo nella proprietà YY nell'oggetto XX" e JSF farà tutto questo.

Quindi sì, puoi ancora usare JQuery, JS, ecc. Ma JSF offre molti vantaggi quando si tratta di scrivere codice lato server e ti salva da un sacco di boiler plate.

— ARG20
fonte

9

Non sono assolutamente d'accordo sul fatto che jsf aggiunga qualcosa. Aggiunge solo un sovraccarico. Fare cose dell'interfaccia utente sul server è la cosa più ridicola che abbia mai sentito. E javascript su grandi team funziona alla grande: si chiama riutilizzo del codice.

Basta avvolgere il jquery in alcuni tag jsp, questo è tutto ciò di cui hai bisogno e il gioco è fatto, e non sopportare i problemi di scalabilità e di scalabilità con.jsf e richfaces.

— guwst
fonte

14

JSF è orientato verso applicazioni basate su form. jQuery è carino (diamine, molte popolari librerie di componenti JSF come PrimeFaces, RichFaces e IceFaces lo usano persino sotto le coperte), ma jQuery non semplifica in alcun modo l'elaborazione dei moduli inviati sul lato server. L'uso di JSP / Servlet semplice risulterà solo in un terribile codice boilerplate. Ancora una volta, JSF non è solo HTML / CSS / JS, ma anche JSP / Servlet.

— BalusC

2

Penso che se leggessi di più su JSF in generale e sul ciclo di vita di una pagina JSF in particolare, potresti cambiare idea. Poi di nuovo, potresti non farlo.

— Ahmed Anwar

5

Avendo lavorato con JSF, Spring MVC, Struts, Grails, JQuery ed ExtJS, la mia opinione è che Grails + ExtJS sia una potente combinazione.

Sceglierei Grails su JSF ogni giorno. Mi piace la completezza di ExtJS come framework e libreria lato client, ma ha una curva di apprendimento più ripida rispetto a JQuery.

— dbrin
fonte

3

Ecco le maggiori differenze tra jQuery e JSF:

nessuna architettura MVC
nessun controllo di stato (memorizza la data nella sessione o conversazione, pulizia automatica, ecc.)
nessuna libreria di convalida (predefinita)
nessuna libreria di modelli
nessuna navigazione / rotta avanzata
dalla parte del cliente

jQuery non è mai stato concepito per essere utilizzato come un webframework full stack. Era più inteso per sostituire il codice JS di basso livello in modo che la scrittura di JS diventasse più facile e più potente con meno righe di codice.

E dovrebbe quindi essere utilizzato principalmente per aggiungere comportamenti agli elementi HTML.

— Serkan
fonte

2

Avendo usato il framework ExtJS per una grande applicazione web, so quanto sia facile da usare. ExtJS (Schena) è più adatto per le interazioni di database (Oracle 11g) nell'architettura MVC. La vista era per le interazioni visive / utente. Il controller ha specificato l '"elaborazione" e i trigger che dovevano essere utilizzati dai pacchetti PLSQL (l'API per CRUD, le query di selezione SQL ecc.). Il modello e i file di archivio sono stati utilizzati per "mappare" gli elementi di dati al visualizzatore / input.

ExtJS non è adatto per interfacce web non ad uso intensivo di database, dove Angular JS potrebbe essere una soluzione migliore.

— Lukas Knaf
fonte