Quali sono i principali svantaggi di Java Server Faces 2.0?

Ieri ho visto una presentazione su Java Server Faces 2.0 che sembrava davvero impressionante, anche se attualmente sono uno sviluppatore felice ASP.NET MVC / jQuery. Quello che mi è piaciuto di più di JSF era l’enorme quantità di componenti UI abilitati per AJAX che sembrano rendere lo sviluppo molto più veloce rispetto a ASP.NET MVC, specialmente sui siti pesanti AJAX. Anche i test di integrazione sono stati molto piacevoli.

Dal momento che la presentazione ha solo enfatizzato i vantaggi di JSF, mi piacerebbe sentire anche l’altra parte.

Quindi le mie domande sono:

  • Quali sono i principali svantaggi di Java Server Faces 2.0?
  • Cosa potrebbe fare uno sviluppatore JSF considerare l’utilizzo di ASP.NET MVC invece di JSF?

Svantaggi di JSF 2.0? Onestamente, a parte la relativa curva di apprendimento quando non si hanno solide conoscenze sullo sviluppo Web di base (HTML / CSS / JS, lato server contro lato client, ecc.) E l’ API Java Servlet di base (richiesta / risposta / sessione , inoltro / reindirizzamento, ecc.) non vengono in mente gravi svantaggi. Nella sua attuale versione, JSF deve ancora eliminare l’immagine negativa che ha acquisito durante i primi anni, durante i quali ci sono stati diversi seri svantaggi.

JSF 1.0 (marzo 2004)

Questa era la versione iniziale. Era pieno di bug sia nel core che nelle aree di performance che non vuoi sapere. La tua webapplication non ha sempre funzionato come ti aspetteresti intuitivamente. Tu come sviluppatore scapperesti a piangere.

JSF 1.1 (maggio 2004)

Questa era la versione del bugfix. La performance non era ancora molto migliorata. C’era anche uno dei principali svantaggi: non è ansible integrare HTML nella pagina JSF in modo impeccabile. Tutto il semplice HTML di vaniglia viene sottoposto a rendering prima dell’albero del componente JSF. È necessario avvolgere tutta la vaniglia normale nei modo che vengano inclusi nell’albero dei componenti JSF. Sebbene questo fosse conforms alle specifiche, questo ha ricevuto molte critiche. Vedi anche ao JSF / Facelets: perché non è una buona idea mescolare JSF / Facelets con tag HTML?

JSF 1.2 (maggio 2006)

Questa è stata la prima versione del nuovo team di sviluppo JSF diretto da Ryan Lubke. Il nuovo team ha fatto un ottimo lavoro. C’erano anche cambiamenti nelle specifiche. Il principale cambiamento è stato il miglioramento della gestione della vista. Questo non solo distava completamente JSF da JSP, quindi si poteva usare una tecnologia di visualizzazione diversa da quella JSP, ma consentiva anche agli sviluppatori di incorporare codice HTML vaniglia semplice nella pagina JSF senza problemi con i . Un altro objective principale del nuovo team è stato il miglioramento delle prestazioni. Durante la vita del Sun JSF Reference Implementation 1.2 (che era il nome in codice Mojarra dalla build 1.2_08, intorno al 2008), praticamente ogni build veniva spedita con miglioramenti di prestazioni (maggiori) accanto alle solite (minori) correzioni di bug.

L’unico serio svantaggio di JSF 1.x (incluso 1.2) è la mancanza di un ambito tra la richiesta e l’ambito della sessione , il cosiddetto ambito di conversazione . Questo ha costretto gli sviluppatori a seccarsi con elementi di input nascosti, query DB non necessarie e / o abusare dell’ambito della sessione ogni volta che si desidera conservare i dati del modello iniziale nella richiesta successiva per elaborare correttamente convalide, conversioni, modifiche del modello e invocazioni di azioni in più applicazioni web complesse. Il dolore potrebbe essere attenuato adottando una libreria di terze parti che conserva i dati necessari nella richiesta successiva come MyFaces Tomahawk componente, scope conversazione JBoss Seam e framework conversazione MyFaces Orchestra .

Un altro svantaggio per i puristi HTML / CSS è che JSF utilizza i due punti : come carattere separatore dell’ID per garantire l’univocità id dell’elemento HTML nell’output HTML generato, specialmente quando un componente viene riutilizzato più di una volta nella vista (template, componenti iterating, eccetera). Poiché si tratta di un carattere illegale negli identificatori CSS, è necessario utilizzare il \ per sfuggire ai due punti nei selettori CSS, risultando in selettori brutti e dall’aspetto strano come #formId\:fieldId {} o persino #formId\3A fieldId {} . Vedi anche Come usare l’ID dell’elemento HTML generato da JSF con i due punti “:” nei selettori CSS? Tuttavia, se non sei un purista, leggi anche Per impostazione predefinita, JSF genera ID inutilizzabili, che sono incompatibili con la parte css degli standard web .

Inoltre, JSF 1.x non è stato spedito con le strutture Ajax fuori dalla scatola. Non proprio uno svantaggio tecnico, ma a causa del clamore del Web 2.0 durante quel periodo, divenne uno svantaggio funzionale. Exadel era presto per introdurre Ajax4jsf, che è stato completamente sviluppato nel corso degli anni e divenne la parte centrale della libreria di componenti di JBoss RichFaces . Altre librerie di componenti sono state fornite con i poteri Ajax integrati , il più noto è ICEfaces .

Circa a metà del tempo di vita di JSF 1.2, è stata introdotta una nuova tecnologia di visualizzazione basata su XML: Facelets . Questo ha offerto enormi vantaggi rispetto a JSP, specialmente nell’area dei modelli.

JSF 2.0 (giugno 2009)

Questa è stata la seconda major release, con Ajax come buzzword. Ci sono stati molti cambiamenti tecnici e funzionali. JSP è sostituito da Facelets come tecnologia di visualizzazione predefinita e Facelets è stato ampliato con funzionalità per la creazione di componenti personalizzati utilizzando puro XML (i cosiddetti componenti compositi ). Vedi anche Perché Facelets è preferito su JSP come lingua di definizione della vista da JSF2.0 in poi?

I poteri Ajax sono stati introdotti nel sapore del componente che ha molte somiglianze con Ajax4jsf. Sono state introdotte annotazioni e miglioramenti della convenzione sulla configurazione per eliminare il più ansible il file verbose faces-config.xml . Inoltre, il carattere del separatore ID del contenitore di denominazione predefinito : diventato configurabile, quindi i puristi HTML / CSS potrebbero essere sollevati. Tutto quello che devi fare è definirlo come init-param in web.xml con il nome javax.faces.SEPARATOR_CHAR e assicurarti che non stai usando il personaggio da solo in nessun ID client, come ad esempio - .

Ultimo ma non meno importante, è stato introdotto un nuovo ambito, l’ambito di visualizzazione . Ha eliminato un altro importante svantaggio JSF 1.x come descritto in precedenza. Basta dichiarare il bean @ViewScoped per abilitare l’ambito della conversazione senza complicare tutti i modi per conservare i dati nelle successive richieste (conversazionali). Un bean @ViewScoped vivrà fino a quando successivamente si @ViewScoped e @ViewScoped alla stessa vista (indipendentemente dalla scheda / finestra del browser aperta!), Sia in modo sincrono che asincrono (Ajax). Vedi anche Differenza tra View e Request scope nei bean gestiti e Come scegliere l’ambito del bean corretto?

Sebbene praticamente tutti gli svantaggi di JSF 1.x siano stati eliminati, ci sono alcuni bug specifici di JSF 2.0 che potrebbero diventare uno showstopper. @ViewScoped esito negativo nei gestori di tag a causa di un problema dell’uovo di gallina nel salvataggio parziale dello stato. Questo problema è stato risolto in JSF 2.2 e eseguito il backport in Mojarra 2.1.18. Anche il passaggio di attributi personalizzati come HTML5 data-xxx non è supportato. Questo problema è stato risolto in JSF 2.2 dalla nuova funzione passthrough elements / attributes. Inoltre l’implementazione di JSF Mojarra ha il suo insieme di problemi . Relativamente molti di essi sono legati al comportamento talvolta non intuitivo di , alla nuova implementazione di salvataggio dello stato parziale e allo scope flash implementato male . Molti di questi sono corretti in una versione di Mojarra 2.2.x.

Intorno al tempo di JSF 2.0, PrimeFaces è stato introdotto, basato su jQuery e jQuery UI. È diventato la libreria di componenti JSF più popolare.

JSF 2.2 (maggio 2013)

Con l’introduzione di JSF 2.2, HTML5 è stato usato come buzzword anche se tecnicamente era supportato solo in tutte le versioni JSF precedenti. Vedi anche JavaServer Faces 2.2 e supporto HTML5, perché XHTML è ancora in uso . La più importante nuova funzionalità di JSF 2.2 è il supporto per gli attributi dei componenti personalizzati, aprendo così un mondo di possibilità, come i gruppi di pulsanti di opzione tableless personalizzati .

A parte l’implementazione di bug specifici e alcune “piccole cose fastidiose” come l’impossibilità di iniettare un bean in un validatore / convertitore (già risolto in JSF 2.3), non ci sono grossi svantaggi nella specifica JSF 2.2.

MVC basato su componente vs MVC basato su richiesta

Alcuni potrebbero optare per il fatto che il principale svantaggio di JSF è che consente un controllo molto preciso su HTML / CSS / JS generato. Quello non è proprio di JSF, è solo perché è un framework MVC basato su componenti , non un framework MVC basato su richiesta (azione) . Se un elevato grado di controllo dell’HTML / CSS / JS è il requisito principale quando si considera un framework MVC, non si dovrebbe già considerare un framework MVC basato su componenti, ma su un framework MVC basato su richiesta come Spring MVC . Devi solo tener conto del fatto che dovrai scrivere tutto ciò che è in HTML / CSS / JS. Vedi anche Differenza tra richiesta MVC e Componente MVC .

Guarda anche:

  • Qual è la differenza tra JSF, Servlet e JSP? (solo per capire le basi)
  • Utilizzo di JSF per sviluppare layout CSS senza tablature (un altro mito su JSF)
  • JSF vs semplice HTML / CSS / JS / jQuery (quando JSF è la scelta sbagliata)
  • Modelli di progettazione nelle applicazioni Web (illustra l’ideologia alla base di MVC)

Dopo 5 anni di lavoro con JSF, penso di poter aggiungere i miei 2 centesimi.

Due importanti inconvenienti JSF :

  1. Grande curva di apprendimento. JSF è complesso, è vero.
  2. La sua natura componente . L’infrastruttura basata su componenti cerca di hide la vera natura del Web, che comporta un’enorme quantità di complicazioni e disastri (come non supportare GET in JSF in quasi 5 anni).
    IMHO che nasconde la richiesta / risposta HTTP dallo sviluppatore è un errore enorme. Dalla mia esperienza, ogni framework basato su componenti aggiunge astrazione allo sviluppo Web e quell’astrazione si traduce in un sovraccarico non necessario e in una maggiore complessità.

E piccoli inconvenienti che mi vengono in mente:

  1. L’ID predefinito dell’object è composto da id dei suoi genitori, ad esempio form1: button1.
  2. Un modo semplice per commentare il frammento della pagina errata. Tag bisogno di contenuti sintatticamente corretti che vengono comunque analizzati.
  3. Componenti di terze parti di bassa qualità che, ad esempio, non verificano isRendered() all’interno del processo processXxx() prima di continuare.
  4. Incorporare LESS e Sencha è difficile.
  5. Non funziona bene con REST.
  6. Non è così facile per i progettisti UX, perché i componenti pronti all’uso hanno i propri stili CSS, che devono essere sovrascritti.

Non fraintendermi. Come un framework di componenti JSF nella versione 2 è davvero buono, ma è ancora basato sui componenti e sarà sempre …

Si prega di dare un’occhiata alla bassa popolarità di Tapestry, Wicket e il basso entusiasmo degli sviluppatori JSF esperti (ciò che è ancora più significativo). E per contrasto, dai un’occhiata al successo di Rails, Grails, Django, Play! Framework: sono tutti basati sull’azione e non cercano di hide la vera richiesta / risposta del programmatore e la natura senza stato del web.

Per me è il principale svantaggio di JSF. IMHO JSF può adattarsi ad alcuni tipi di applicazioni (intranet, ad alta intensità di moduli), ma per le applicazioni Web reali non è un buon modo per andare.

Spero che aiuti qualcuno con le sue scelte riguardo al front-end.

Alcuni inconvenienti che ti vengono in mente:

  1. JSF è un framework basato su componenti. Questo ha restrizioni intrinseche che hanno a che fare con l’obbedienza al modello del componente.
  2. AFAIK JSF supporta solo POST, quindi se vuoi un GET da qualche parte devi fare un semplice servlet / JSP.
  3. La maggior parte dei componenti cerca di fornire astrazioni su domini come database relazionali e JavaScript front-end, e molte volte queste astrazioni sono “leaky” e molto difficili da eseguire il debug.
  4. Queste astrazioni potrebbero essere un buon punto di partenza per uno sviluppatore junior o qualcuno che non si sente a proprio agio con un particolare dominio (es. JavaScript front-end), ma sono molto difficili da ottimizzare per le prestazioni, dal momento che ci sono diversi livelli coinvolti e la maggior parte delle persone che li usano avere poca comprensione di cosa sta succedendo sotto il cofano.
  5. I meccanismi di template che sono solitamente usati con JSF non hanno nulla a che fare con il funzionamento dei web desigers. Gli editor WYSIWYG per JSF sono primitivi e, in ogni caso, il tuo designer ti fornirà HTML / CSS che dovrai convertire per età.
  6. Cose come le espressioni EL non sono controllate staticamente e sia il compilatore che gli IDE non stanno facendo un buon lavoro nel trovare errori, quindi finirai con errori che dovrai catturare in fase di esecuzione. Questo potrebbe andar bene per un linguaggio tipizzato dynamicmente come Ruby o PHP, ma se devo sopportare il puro stravolgimento dell’ecosistema Java, richiedo la digitazione per i miei modelli.

Per riassumere: il tempo che salverete con JSF, evitando di scrivere il codice JSP / servlet / beanplate, lo spenderete x10 per ridimensionarlo e fare esattamente ciò che volete che faccia.

Per me il più grande svantaggio di JSF 2.0 è la curva di apprendimento non solo di JSF, ma le librerie di componenti che devi usare per fare in modo che funzioni. Considera l’incredibile numero di specifiche e standard con cui hai a che fare per essere davvero competente:

  • HTML nelle varie incarnazioni. Non fingere di non aver bisogno di saperlo.
  • HTTP: quando non riesci a capire cosa sta succedendo, devi aprire Firebug e vedere. Per quello devi sapere questo.
  • CSS: piaccia o no Non è così male davvero e ci sono alcuni strumenti carini là fuori almeno.
  • XML – JSF sarà probabilmente il primo posto in cui usi lo spazio dei nomi in questa misura.
  • Specifica servlet. Prima o poi entrerai in metodi di chiamata in questo pacchetto. A parte questo, devi sapere come i tuoi Facelets vengono trasformati in XHTML o altro.
  • JSP (soprattutto perché sai perché non ne hai bisogno in JSF)
  • JSTL (di nuovo, principalmente per far fronte al framework legacy)
  • Expression Language (EL) nelle sue varie forms.
  • ECMAScript, JavaScript o qualsiasi altra cosa si voglia chiamare.
  • JSON – dovresti saperlo anche se non lo usi.
  • AJAX. Direi che JSF 2.0 fa un lavoro decente nel nasconderlo, ma devi ancora sapere cosa sta succedendo.
  • Il DOM. E come lo usa un browser. Vedi ECMAScript.
  • Eventi DOM: un argomento tutto da solo.
  • Java Persistence Architecture (JPA) che è se vuoi che la tua app abbia una base dati back-end.
  • Java stesso.
  • JSEE mentre ci sei.
  • La specifica di Context Dependency Injection (CDI) e in che modo si scontra con e viene utilizzata con JSF 2.0
  • JQuery – Mi piacerebbe vederti andare d’accordo senza di esso.

Ora, una volta che hai finito puoi andare avanti con le specifiche proprietarie, vale a dire le librerie dei componenti e le librerie dei provider che raccoglierai lungo il percorso:

  • PrimeFaces (la mia libreria di componenti di scelta)
  • RichFaces
  • MyFaces
  • ICEfaces
  • EclipseLink (il mio provider JPA)
  • hibernate
  • saldare

E non dimenticare il contenitore! E tutti quei file di configurazione:

  • GlassFish (2, 3, ecc.)
  • JBoss
  • micio

Quindi – QUESTO È FACENDO FACILE? Certo, JSF 2.0 è “facile” a patto che tutto ciò che vuoi è la più semplice delle pagine web con le interazioni più semplici.

In poche parole, JSF 2.0 è il miscuglio più complicato e ingombrante di tecnologie incollate insieme che esiste oggi nell’universo del software. E non riesco a pensare a qualcosa che preferirei usare.

“JSF emetterà HTML e JavaScript a livello di vista che non puoi controllare o modificare senza entrare nel codice del controller.”

In realtà, JSF ti dà la flessibilità, puoi utilizzare componenti standard / di terze parti o crearne di tuoi che hai il pieno controllo su ciò che viene reso. È solo un xhtml che devi creare i tuoi componenti personalizzati con JSF 2.0.

  1. Gli sviluppatori inesperti solitamente creeranno applicazioni che sono dolorosamente lente e il codice sarà davvero brutto e difficile da mantenere. È ingannevolmente semplice da avviare, ma in realtà richiede un certo investimento nell’apprendimento se si desidera scrivere buoni programmi.
  2. Almeno all’inizio ti troverai spesso “bloccato” su qualche problema e passerai più tempo a leggere i messaggi di balusc su internet piuttosto che lavorare 🙂 Dopo un po ‘sarà sempre meno, ma può comunque essere fastidioso.
  3. Ancora più fastidioso quando si scopre che il problema non è dovuto alla mancanza di conoscenza / errore, ma in realtà a un bug. Mojarra era (è?) Abbastanza buggato, e un altro strato di componenti aggiunge ancora più problemi. Richfaces è stato il più grande pezzo di software di merda mai scritto 🙂 Non so come sia ora nella versione 4. Abbiamo Primefaces che è meglio, ma comunque ti imbatterai in bug o mancanza di funzionalità, specialmente con componenti più esotici. E ora dovrai pagare per gli aggiornamenti Primefaces. Quindi direi il suo bug, ma sta migliorando soprattutto dopo che la versione 2.2 ha risolto alcuni problemi con le specifiche. Quadro sempre più maturo ma ancora lontano dall’essere perfetto (forse il mio aspetto migliore?).
  4. Non lo trovo particolarmente flessibile. Spesso se hai bisogno di qualcosa di molto personalizzato e non ci sono componenti che lo facciano – sarà un po ‘doloroso. Di nuovo parlo dal punto di vista dello sviluppatore medio – quello con scadenze, tutorial di lettura rapida e ricerca di stackoverflow quando si blocca perché non c’è tempo per imparare come funziona davvero 🙂 Spesso alcuni componenti sembrano avere “quasi” ciò di cui hai bisogno, ma non esattamente e qualche volta potresti spendere troppo tempo per fargli fare qualcosa che vuoi 🙂 Bisogna stare attenti nel valutare se è meglio creare il proprio o torturare un componente esistente. In realtà se stai creando qualcosa di davvero unico non consiglierei JSF.

Quindi, in breve, i miei svantaggi sarebbero: complessità, progresso di sviluppo non molto fluido, bug, inflessibile.

Naturalmente ci sono anche dei vantaggi, ma non è quello che hai chiesto. Comunque questa è la mia esperienza con framework altri potrebbero avere opinioni diverse, quindi il modo migliore è provarlo per un po ‘per vedere se è per te (solo qualcosa di più complesso – non esempi ingenui – JSF brilla davvero lì 🙂 IMHO best use case for JSF è applicazioni aziendali, come CRM ecc …

Abbiamo sviluppato un progetto di esempio con JSF (era una ricerca di tre settimane, quindi potremmo aver perso alcune cose!)

Cerchiamo di utilizzare core jsf, se è necessario un componente abbiamo usato PrimeFaces.

Il progetto era un sito web con navigazione. Ogni pagina deve essere caricata tramite ajax quando si fa clic sul menu.

Il sito ha due casi d’uso:

  1. Una pagina con una griglia. La griglia viene caricata tramite ajax e dovrebbe supportare l’ordinamento e il paging
  2. Una pagina della procedura guidata in tre fasi. Ogni pagina ha validazione lato client (per convalide semplici) e convalida base ajax lato server (per convalide complesse). Qualsiasi eccezione del server (dal livello di servizio) dovrebbe essere visualizzata sulla stessa pagina della procedura guidata senza passare alla pagina successiva.

L’abbiamo trovato:

  1. È necessario utilizzare alcuni hack da omniFaces per correggere lo stato di visualizzazione JSF. Lo stato JSF sarà danneggiato quando includi pagine tramite Ajax l’una nell’altra. Questo sembra un bug in JSF e potrebbe essere corretto sulle prossime release (non in 2.3).
  2. Il stream JSF non funziona correttamente con ajax (o non siamo in grado di farlo funzionare!) Proviamo a utilizzare invece il componente wizard di primeface, ma la convalida del client sembra non supportata e non significa che non fosse standard standard di stream JSF.
  3. Quando si utilizzano alcuni componenti jQuery come jqGird e si devono caricare i risultati JSON, si consiglia di utilizzare servlet puro. Il JSF non farà nulla per te. Quindi, se utilizzi questo tipo di componenti, il tuo design non si adatta a JSF.
  4. Proviamo a fare alcuni script client quando ajax è completato da ajaxComplete e abbiamo scoperto che il PF 4 ha implementato i propri eventi ajaxComplete . Avevamo alcuni componenti jQuery e abbiamo bisogno di cambiare il loro codice.

Se si modifica il campione di cui sopra in un progetto non Ajax (o almeno in un progetto ajax inferiore) non si troveranno ad affrontare molti problemi di cui sopra.

Riassumiamo la nostra ricerca come:

JSF non sta funzionando bene in un sito web di base completamente ajax.

Naturalmente in JSF troviamo molte funzioni interessanti che potrebbero essere molto utili in alcuni progetti, quindi considera le esigenze del tuo progetto.

Si prega di fare riferimento ai documenti tecnici JSF per rivedere i vantaggi di JSF e, a mio parere, il più grande vantaggio di JSF, è il supporto COMPLETO E ENORME di @BalusC 😉

Non sono affatto un esperto di Java Server. Ma IMHO lo svantaggio principale è che è lato server. Sono stanco di apprendere e utilizzare framework di livelli di presentazione Web lato server come ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, framework php e framework ruby ​​on rails. Ho salutato tutti e ho salutato Angularjs e TypeScript. Il mio livello di presentazione viene eseguito sul browser. Non importa se è servito da Windows IIS che esegue php o ASP.NET, o se è servito da un server web Apache in esecuzione su Linux. Ho solo bisogno di imparare solo un framework che funziona ovunque.

Solo i miei due centesimi.

Per me la più grande mancanza di JSF è il supporto scarso per pagine generate dynamicmente (in modo dinamico).
Se vuoi build la tua pagina (crea il modello di componente della pagina) dynamicmente dal codice java. Ad esempio se si sta lavorando su un costruttore di pagine Web WYSIWYG. Una documentazione adeguata di questo caso d’uso non è generalmente disponibile. Ci sono molti punti in cui devi sperimentare e lo sviluppo è lento e lento. Molte cose non funzionano come ti aspetteresti. Ma generalmente è ansible modificarlo in qualche modo.
La cosa buona è che non è un problema in filosofia o architettura di JSF. Semplicemente non sufficientemente elaborato (per quanto ne so).

JSF 2 ha portato Composite Components che dovrebbe rendere facile lo sviluppo di componenti, ma il loro supporto per la costruzione dynamic (programmatica) è molto scarso. Se superi un processo complicato e quasi senza documenti di costruzione di componenti compositi dinamici, scoprirai che se nidifichi pochi componenti Composite poco più in profondità, smettono di funzionare, facendo alcune eccezioni.

Ma sembra che la comunità JSF sia consapevole di queste carenze. Stanno lavorando su questo come puoi vedere da questi due bug
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

La situazione dovrebbe essere migliore con JSF 2.2, almeno se stiamo parlando di specifiche.

Commentando i miei ultimi mesi di esperienza Primefaces / JSF:

  • Se è ansible utilizzare i componenti “dallo scaffale”, immagino che non sia terribile.
  • Tuttavia, non gioca bene non appena esci e hai bisogno di interfacce utente personalizzate. – Ad esempio, dovevamo utilizzare il bootstrap di Twitter per il nostro progetto. (Non bootfaces primario).
    • Ora le nostre pagine funzionano come segue:
      • Caricamento della pagina.
      • L’utente interagisce con un Primefaces che ha una funzionalità Ajax
      • I collegamenti javascript di Bootstrap si interrompono
      • Eseguiamo javascript in più per riassociare tutto

La promise di JSF di evitare di scrivere javascript si è trasformata in una scrittura più javascript di quella che avremmo se non avessimo usato Primefaces – e in questo javascript è stato risolto ciò che Primefaces ha infranto.

È una perdita di tempo – a meno che tu non usi di nuovo “roba da scaffale”. Davvero brutto (Primefaces) quando si deve lavorare con il selenium. Tutto può essere fatto – ma ancora una volta – c’è solo tanto tempo.

Evitatelo di sicuro se state lavorando con un team di progettazione / UX e avete bisogno di eseguire una rapida iterazione nell’interfaccia utente – potete risparmiare tempo imparando jquery / scrivendo direttamente HTML – o guardando a reactjs / angular.

JSF ha molti vantaggi, la domanda essendo in svantaggio lasciatemi aggiungere un paio di punti su di esso.

In uno scenario pratico di implementazione di un progetto web in un arco di tempo è necessario tenere d’occhio i seguenti fattori.

  • Hai abbastanza membri senior nel tuo team che possono suggerire i migliori controlli adatti per ogni scenario?
  • Hai la larghezza di banda per accogliere la curva di apprendimento iniziale?

  • Hai abbastanza esperienza nel tuo team che può rivedere la JSF
    roba prodotta dagli sviluppatori?

Se la tua risposta è “No” per le domande, potresti finire con una base di codice non gestibile.

JSF ha solo uno svantaggio: prima di iniziare lo sviluppo di “JSF” dovresti capire chiaramente lo sviluppo web, l’architettura core java e front-end.

Oggigiorno i “nuovi” framework JavaScript cercano solo di copiare / incollare il modello basato su componenti “JSF”.

Among all the “mainstream” frameworks such as Spring MVC, Wicket, Tapestry, etc., the JSF of Java EE with its composite components is the most elaborated presentation-layer and component-oriented technology provided. It is a bit cumbersome and incomplete compared to solutions provided by HybridJava.