Quali sono i principali svantaggi di Java Server Faces 2.0?

StackOverflow https://stackoverflow.com/questions/3623911

  •  26-09-2019
  •  | 
  •  

Domanda

Ieri ho visto una presentazione su Java Server Faces 2.0 che sembrava davvero impressionante, anche se attualmente sono un felice sviluppatore ASP.NET MVC / jQuery.Ciò che mi è piaciuto di più di JSF è stata l'enorme quantità di componenti dell'interfaccia utente abilitati per AJAX che sembrano rendere lo sviluppo molto più veloce rispetto a ASP.NET MVC, specialmente su siti con uso pesante di AJAX.Anche i test di integrazione sembravano molto interessanti.

Dato che la presentazione ha sottolineato solo i vantaggi di JSF, mi piacerebbe conoscere anche l'altro lato.

Quindi le mie domande sono:

  • Quali sono i principali svantaggi di Java Server Faces 2.0?
  • Cosa potrebbe indurre uno sviluppatore JSF a prendere in considerazione l'utilizzo di ASP.NET MVC anziché JSF?
È stato utile?

Soluzione

Svantaggi di JSF 2.0?Onestamente, a parte la relativa curva di apprendimento ripida quando non si dispone di una solida conoscenza di base Sviluppo Web di base (HTML/CSS/JS, lato server rispetto a lato client, ecc.) e il file API servlet Java di base (richiesta/risposta/sessione, inoltro/reindirizzamento, ecc.), non vengono in mente seri svantaggi.JSF nella sua versione attuale deve ancora liberarsi dell'immagine negativa che si è guadagnata durante i primi anni, durante i quali presentava diversi gravi svantaggi.

JSF 1.0 (marzo 2004)

Questa era la versione iniziale.Era pieno di bug sia nell'area principale che in quella delle prestazioni di cui non volevi sapere.La tua applicazione web non ha sempre funzionato come ti aspetteresti intuitivamente.Tu come sviluppatore scapperesti via piangendo.

JSF 1.1 (maggio 2004)

Questa era la versione di correzione del bug.Le prestazioni non erano ancora migliorate di molto.C'era anche un grosso svantaggio:non è possibile incorporare l'HTML nella pagina JSF in modo impeccabile.Viene eseguito il rendering di tutto il semplice codice HTML Vanilla Prima l'albero dei componenti JSF.Devi avvolgere tutta la semplice vaniglia <f:verbatim> tag in modo che vengano inclusi nell'albero dei componenti JSF.Sebbene fosse conforme alle specifiche, ha ricevuto molte critiche.Vedi anche a.o. JSF/Facelet: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 guidato da Ryan Lubke.La nuova squadra ha fatto un ottimo lavoro.Ci sono stati anche cambiamenti nelle specifiche.Il cambiamento principale è stato il miglioramento della gestione della vista.Ciò non solo ha separato completamente JSF da JSP, quindi è possibile utilizzare una tecnologia di visualizzazione diversa da JSP, ma ha anche consentito agli sviluppatori di incorporare HTML semplice nella pagina JSF senza problemi con <f:verbatim> tag.Un altro obiettivo importante della nuova squadra era migliorare le prestazioni.Durante il ciclo di vita dell'implementazione di riferimento Sun JSF 1.2 (nome in codice Mojarra dalla build 1.2_08, intorno al 2008), praticamente ogni build è stata fornita con (importanti) miglioramenti delle prestazioni accanto alle solite (minori) correzioni di bug.

L'unico grave svantaggio di JSF 1.x (incluso 1.2) è la mancanza di un ambito tra i file richiesta E sessione ambito, il cosiddetto conversazione scopo.Ciò ha costretto gli sviluppatori a confrontarsi con elementi di input nascosti, query DB non necessarie e/o ad abusare dell'ambito della sessione ogni volta che si desidera conservare i dati del modello iniziale nella richiesta successiva per elaborare con successo convalide, conversioni, modifiche del modello e invocazioni di azioni in più applicazioni web complesse.Il problema potrebbe essere attenuato adottando una libreria di terze parti che conservi i dati necessari nella richiesta successiva MyFaces Tomahawk <t:saveState> componente, JBoss cucitura ambito della conversazione e Orchestra MyFaces quadro di conversazione.

Un altro svantaggio per i puristi di HTML/CSS è che JSF utilizza i due punti : come carattere separatore ID per garantire l'unicità dell'elemento HTML id nell'output HTML generato, soprattutto quando un componente viene riutilizzato più di una volta nella vista (template, iterazione dei componenti, ecc.).Poiché questo è un carattere illegale negli identificatori CSS, dovresti utilizzare il file \ per sfuggire ai due punti nei selettori CSS, risultando in selettori brutti e dall'aspetto strano come #formId\:fieldId {} o anche #formId\3A fieldId {}.Guarda anche Come utilizzare 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 veniva fornito con le funzionalità Ajax pronte all'uso.Non proprio uno svantaggio tecnico, ma a causa dell'hype del Web 2.0 in quel periodo, è diventato uno svantaggio funzionale. Exadel è stato presto per introdurre Ajax4jsf, che è stato sviluppato a fondo nel corso degli anni e ne è diventato la parte centrale JBoss RichFaces libreria di componenti.Anche un'altra libreria di componenti è stata fornita con poteri Ajax incorporati, quella ben nota è ICEfaces.

Circa a metà del ciclo di vita di JSF 1.2, è stata introdotta una nuova tecnologia di visualizzazione basata su XML: Facelette.Ciò offriva enormi vantaggi rispetto a JSP, soprattutto nell'area dei template.

JSF 2.0 (giugno 2009)

Questa è stata la seconda major release, con Ajax come parola d'ordine.Ci sono state molte modifiche tecniche e funzionali.JSP è stato sostituito da Facelets come tecnologia di visualizzazione predefinita e Facelets è stato ampliato con funzionalità per creare componenti personalizzati utilizzando XML puro (il cosiddetto componenti compositi).Guarda anche Perché Facelets è preferito a JSP come linguaggio di definizione della vista da JSF2.0 in poi?

I poteri dell'Ajax furono introdotti nel gusto del <f:ajax> componente che ha molte somiglianze con Ajax4jsf.Sono state introdotte annotazioni e miglioramenti delle convenzioni rispetto alla configurazione uccisione il verboso faces-config.xml archiviare il più possibile.Inoltre, il carattere separatore dell'ID contenitore di denominazione predefinito : è diventato configurabile, così i puristi di HTML/CSS potevano tirare un sospiro di sollievo.Tutto quello che devi fare è definirlo come init-param In web.xml con il nome javax.faces.SEPARATOR_CHAR e assicurarti di non utilizzare tu stesso il personaggio in nessun punto degli ID cliente, ad esempio -.

Non ultimo, è stato introdotto un nuovo ambito, il visualizzazione scopo.Ha eliminato un altro importante svantaggio di JSF 1.x, come descritto in precedenza.Dichiari semplicemente il fagiolo @ViewScoped per abilitare l'ambito della conversazione senza problemi con tutti i modi per conservare i dati nelle successive richieste (conversazionali).UN @ViewScoped bean vivrà finché successivamente invierai e navigherai nella stessa vista (indipendentemente dalla scheda/finestra del browser aperta!), in modo sincrono o asincrono (Ajax).Guarda anche Differenza tra l'ambito Visualizza e Richiesta nei bean gestiti E Come scegliere il bean scope giusto?

Anche se praticamente tutti gli svantaggi di JSF 1.x sono stati eliminati, ci sono bug specifici di JSF 2.0 che potrebbero diventare un ostacolo.IL @ViewScoped fallisce nei gestori di tag a causa di un problema di uova di gallina nel salvataggio parziale dello stato.Questo problema è stato risolto in JSF 2.2 ed è stato eseguito il backport in Mojarra 2.1.18.Anche passando attributi personalizzati come HTML5 data-xxx non è supportato.Questo problema è stato risolto in JSF 2.2 dalla nuova funzionalità di elementi/attributi passthrough.Inoltre Mojarra ha implementato JSF la propria serie di problemi.Relativamente molti di essi sono legati a comportamento a volte non intuitivo di <ui:repeat>, IL nuova implementazione del salvataggio parziale dello stato e il ambito flash mal implementato.La maggior parte di essi sono stati risolti nella versione Mojarra 2.2.x.

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

JSF 2.2 (maggio 2013)

Con l'introduzione di JSF 2.2, HTML5 è stato utilizzato come parola d'ordine anche se tecnicamente era supportato solo in tutte le versioni JSF precedenti.Guarda anche Supporto JavaServer Faces 2.2 e HTML5, perché XHTML è ancora in uso.La novità più importante di JSF 2.2 è il supporto per gli attributi dei componenti personalizzati, aprendo così un mondo di possibilità, come gruppi di pulsanti di opzione senza tabella personalizzati.

A parte i bug specifici dell'implementazione e alcune "piccole cose fastidiose" come l'impossibilità di inserire un EJB in un validatore/convertitore (già risolto in JSF 2.3), non ci sono grossi svantaggi nelle specifiche JSF 2.2.

MVC basato su componenti e MVC basato su richiesta

Alcuni potrebbero ritenere che lo svantaggio principale di JSF sia che consente un controllo molto limitato sull'HTML/CSS/JS generato.Non è di proprietà di JSF, è solo perché è un basato sui componenti Framework MVC, non a richiesta (azione) basata struttura MVC.Se un elevato grado di controllo di HTML/CSS/JS è il tuo requisito principale quando consideri un framework MVC, allora non dovresti già guardare a un framework MVC basato su componenti, ma a un framework MVC basato su richiesta come Primavera MVC.Devi solo tenere presente che dovrai scrivere tu stesso tutto il codice HTML/CSS/JS.Guarda anche Differenza tra Richiesta MVC e Componente MVC.

Guarda anche:

Altri suggerimenti

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

Due maggiore JSF svantaggi:

  1. Grande curva di apprendimento.JSF è complesso, è proprio vero.
  2. Suo componente natura.Il framework basato su componenti cerca di nascondere la vera natura del Web, che comporta un'enorme quantità di complicazioni e disastri (come il mancato supporto di GET in JSF entro quasi 5 anni).
    IMHO nascondere la richiesta/risposta HTTP allo sviluppatore è un errore enorme.Dalla mia esperienza, ogni framework basato su componenti aggiunge astrazione allo sviluppo Web e tale astrazione si traduce in un sovraccarico non necessario e in una maggiore complessità.

E minore inconvenienti che mi vengono in mente:

  1. Per impostazione predefinita, l'ID dell'oggetto è composto dagli ID dei suoi genitori, ad esempio form1:button1.
  2. Non esiste un modo semplice per commentare il frammento di pagina errato.Etichetta <ui:remove> necessita di contenuto sintatticamente corretto che viene comunque analizzato.
  3. Componenti di terze parti di bassa qualità che ad es.non controllare isRendered() dentro processXxx() metodo 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 framework a componenti, JSF nella versione 2 è davvero buono, ma è ancora basato su componenti e lo sarà sempre...

Dai un'occhiata alla scarsa popolarità di Tapestry, Wicket e allo scarso entusiasmo degli sviluppatori JSF esperti (cosa ancora più significativa).E per contrasto, dai un'occhiata al successo di Rails, Grails, Django, Play!Framework: sono tutti basati sull'azione e non cercano di nascondersi dal programmatore richiesta/risposta vera E natura apolide della rete.

Per me è il principale svantaggio di JSF.IMHO JSF può adattarsi ad alcuni tipi di applicazioni (intranet, ad alta intensità di moduli), ma per la vita reale ragnatela applicazione non è una buona strada da percorrere.

Spero che aiuti qualcuno con le sue scelte per quanto riguarda il front-end.

A pochi svantaggi che compaiono in mente:

  1. JSF è un framework basato su componenti. Questo ha limitazioni intrinseche che hanno a che fare con obbedire alla componente-modello.
  2. Per quanto ne sappia JSF supporta solo POST, quindi se volete un posto GET avete per fare un servlet pianura / JSP.
  3. La maggior parte dei componenti cercano di fornire astrazioni su domini come database relazionali e di front-end JavaScript, e molte volte questi astrazioni sono "perde" e molto difficile da mettere a punto.
  4. Queste astrazioni potrebbe essere un buon punto di partenza per uno sviluppatore junior o qualcuno non agio con un particolare dominio (ad esempio, front-end JavaScript), ma sono molto difficili per ottimizzare le prestazioni, dato che ci sono diversi strati coinvolti, e la maggior parte delle persone che l'uso di loro hanno poca comprensione di ciò che sta accadendo sotto il cofano.
  5. I meccanismi di templating che di solito vengono utilizzati con JSF non hanno nulla a che fare con il modo in web desigers lavoro. Gli editor WYSIWYG per JSF sono primitivi e, in ogni caso, il progettista vi darà HTML / CSS che dovrete spendere età conversione.
  6. Le cose come le espressioni EL non vengono controllati in modo statico e sia il compilatore e IDE non stanno facendo un buon lavoro a errori di trovare, così potrai finire con gli errori che dovrete cattura a run-time. Questo potrebbe andare bene per il linguaggio dinamicamente tipizzati come Ruby o PHP, ma se devo sopportare la pura gonfiare dell'ecosistema Java, esigo tipizzazione per i miei modelli.

Per riassumere: Il tempo si risparmia con JSF, da evitare di scrivere il / servlet / fagiolo codice standard JSP, avrete speso x10 per renderlo scala e fare esattamente quello che voglio fare.

Per me il più grande svantaggio di JSF 2.0 è la curva di apprendimento non solo di JSF, ma le librerie di componenti che si deve utilizzare al fine di arrivare a fare un lavoro utile. Si consideri il numero impressionante di specifiche e standard si deve affrontare per davvero essere abile:

  • HTML nelle varie incarnazioni. Non far finta di non c'è bisogno di saperlo.
  • HTTP - quando non si riesce a capire cosa sta succedendo bisogna aprire Firebug e vedere. Per questo è necessario sapere questo.
  • CSS - piaccia o no. Non è così male davvero e ci sono alcuni strumenti belle là fuori almeno.
  • XML -. JSF sarà probabilmente il primo luogo di utilizzare gli spazi dei nomi fino a questo punto
  • Servlet Specification. Prima o poi si otterrà in chiamando i metodi in questo pacchetto. A parte che si deve sapere come il vostro Facelets ottiene trasformato in XHTML o qualsiasi altra cosa.
  • JSP (per lo più in modo da sapere il motivo per cui non è necessario in JSF)
  • JSTL (ancora una volta, per lo più per far fronte quadro legacy)
  • Expression Language (EL) nelle sue varie forme.
  • ECMAScript, JavaScript, o qualsiasi altra cosa si voglia chiamare.
  • JSON -. Si dovrebbe sapere questo, anche se non ne fanno uso
  • AJAX. Direi JSF 2.0 fa un lavoro decente di nascondere questo da voi, ma è comunque necessario sapere che cosa sta succedendo.
  • Il DOM. E come un browser utilizza. Vedere ECMAScript.
  • DOM Eventi -. Un argomento da sola
  • Java Persistence Architecture (APP) che è se si desidera la vostra applicazione di avere qualsiasi base di dati back-end.
  • Java stesso.
  • JSEE mentre si è in esso.
  • Il Dependency Injection specifica Context (CDI) e come si scontra con e viene utilizzato con JSF 2.0
  • JQuery -. Mi piacerebbe vedere che si ottiene avanti senza di essa

Ora, una volta che hai finito con che si può andare avanti con le specifiche di proprietà, vale a dire le librerie di componenti e le librerie del provider si prenderà lungo il percorso:

  • primefaces (la mia libreria di componenti di scelta)
  • RichFaces
  • MyFaces
  • ICEfaces
  • EclipseLink (il mio JPA Provider)
  • Sospensione
  • Weld

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

  • GlassFish (2, 3, ecc)
  • JBoss
  • Tomcat

Quindi - questo è che la rende facile? Certo, JSF 2.0 è "facile" il tempo che tutto quello che vogliamo fare è sulle pagine web di base la maggior parte con le interazioni più semplici.

In poche parole, JSF 2.0 è la più complicata e ingombrante guazzabuglio di tecnologie insieme incollati come esiste nell'universo software di oggi. E non riesco a pensare a niente avrei preferito usare.

  1. sviluppatori inesperti di solito creerà applicazioni che sono dolorosamente lenta e il codice sarà veramente brutto e difficile da mantenere. La sua semplice ingannevolmente per iniziare, ma in realtà richiede un certo investimento in apprendimento se si vuole scrivere buoni programmi.
  2. Almeno All'inizio si trovano spesso "bloccato" su qualche problema e passare più tempo a leggere i messaggi balusc su internet che in realtà lavora :) Dopo un po 'sarà sempre meno di quello, ma ancora può essere fastidioso .
  3. Ancora più fastidioso quando si scopre che il problema non è dovuto alla mancanza di conoscenza si / errore, ma in realtà un bug. Mojarra era (è?) Abbastanza buggy, e un altro strato di componenti aggiunge ancora più problemi. RichFaces era più grande pezzo di software merda mai scritto :) Non so come è ora in versione 4. Abbiamo primefaces che è meglio, ma ancora vi imbatterete in errori o mancanza di caratteristiche in particolare con i componenti più esotiche. E ora sarà necessario pagare per gli aggiornamenti primefaces. Quindi direi che il suo buggy ma la sua sempre meglio soprattutto dopo 2.2 versione fissa alcuni problemi con spec. Quadro sempre più maturo, ma ancora lontano dall'essere perfetto (forse MyFaces meglio?).
  4. non trovo particolarmente flessibile. Spesso se avete bisogno di qualcosa di molto molto personalizzati e non ci sono componenti che non che - sarà un po 'doloroso. Anche in questo caso sto parlando dal punto di vista media sviluppatore - quella con le scadenze, esercitazioni di lettura veloce, e la ricerca StackOverflow quando ottenere bloccati perché non c'è tempo per imparare come funziona davvero :) Spesso alcuni componenti sembra avere "quasi" che cosa avete bisogno, ma non esattamente e, a volte si potrebbe spendere troppo tempo per fargli fare qualcosa che si desidera :) necessario stare attenti nel valutare se il suo meglio per creare il proprio o torturare componente esistente. In realtà se si sta creando qualcosa di veramente unico non mi consiglia JSF.

Così, in breve i miei svantaggi sarebbero:. Complessità, non molto corretto svolgimento di sviluppo, buggy, inflessibile

Naturalmente ci sono vantaggi troppo, ma non è quello che hai chiesto. In ogni caso questo è il mio esperienza con gli altri framework potrebbe avere opinioni diverse, in modo modo migliore è quello di provare solo per un po 'per vedere se per voi (solo qualcosa di più complesso - esempi non ingenuo - JSF brilla davvero lì :) IMHO miglior caso d'uso per JSF è applicazioni aziendali, quali CRM ecc ...

"uscita JSF volontà View-strato di HTML e JavaScript che non si può controllare o cambiamenti senza andare in codice di controllo."

In realtà JSF offre la flessibilità, è possibile utilizzare i componenti / di terze parti standard o creare il proprio quale si ha il pieno controllo su ciò che viene reso. E 'solo una xhtml è necessario creare i componenti personalizzati con JSF 2.0.

Abbiamo messo a punto un progetto di esempio con JSF (E 'stata una ricerca di tre settimane in modo da possiamo avere perdere alcune cose!)

Cerchiamo di usare JSF nucleo, se è necessario un componente abbiamo usato primefaces.

Il progetto è stato un sito web con navigazione. Ogni pagina deve essere caricata tramite la tecnologia AJAX quando viene cliccato il menu.

Il sito ha due casi d'uso:

  1. Una pagina con una griglia. La griglia viene caricato tramite ajax e dovrebbe sostenere ordinamento e paging
  2. Una pagina della procedura guidata in tre fasi. Ogni pagina ha la validazione lato client (per semplici convalide) e la convalida di base Ajax lato server (per le convalide complesse). Ogni eccezione del server (da livello di servizio) deve essere visualizzato sulla stessa pagina della procedura guidata senza navigare alla pagina successiva.

Abbiamo trovato che:

  1. È necessario utilizzare alcuni hack da omniFaces per rendere lo stato di visualizzazione JSF fisso. Lo stato JSF sarà danneggiato quando si includono le pagine tramite la tecnologia AJAX in un l'altro. Questo sembra un bug in JSF e può essere fissato sulla prossima release (non in 2.3).
  2. Il flusso JSF non funziona correttamente con l'Ajax (o non siamo riusciti a farlo funzionare!) Cerchiamo di usare componente guidata primefaces invece, ma la validazione client non sembra sostenuti e intendiamo mentre non era standard flusso JSF standard.
  3. Quando si utilizza alcuni componenti jQuery come jqGird, ed è necessario caricare i risultati JSON, quindi si consiglia di utilizzare servlet puro, il JSF non farà nulla per voi. Quindi, se si utilizza questo tipo di componenti, il vostro disegno non è adatta a JSF.
  4. che cerchiamo di fare alcuni script client quando ajax completa da ajaxComplete e abbiamo scoperto che il PF 4 ha implementato i propri eventi Ajax. Abbiamo avuto alcuni componenti jQuery e abbiamo bisogno di cambiare il loro codice.

Se si modifica l'esempio di cui sopra per un Ajax progetto no (o almeno meno ajax progetto) non sarà un sacco di faccia sopra i problemi.

riassumere la nostra ricerca come:

  

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

Naturalmente troviamo un sacco di belle caratteristiche in JSF, che possono essere molto utili in alcuni progetti, in modo da considerare le vostre esigenze di progetto.

Si prega di fare riferimento al JSF documenti tecnici per vantaggi recensione JSF, e, a mio parere il più grande vantaggio di JSF, è il supporto completo ed enorme da @BalusC; -)

Non sono un server Java Faces esperto a tutti. Ma secondo me il principale svantaggio è che è lato server. Sono stanco di apprendimento e l'utilizzo di server di presentazione web lato quadri di livello come Forms ASP.NET Web, ASP.NET MVC, Java Server Faces, Struts, framework PHP e Ruby on Rails framework. Ho detto addio a tutti loro, e ho detto ciao a Angularjs e dattiloscritto. Il mio livello di presentazione viene eseguito sul browser. Io non importa se è servito da Windows IIS eseguendo PHP o ASP.NET, o se è servito da un server web Apache in esecuzione su Linux. Ho solo bisogno di imparare solo una struttura che funziona ovunque.

Solo i miei due centesimi.

Per me il più grande difetto del JSF è scarso supporto per livello di programmazione pagine (dinamico) generati.
Se si vuole costruire la tua pagina (generazione pagina modello a componenti) in modo dinamico dal codice Java. Per esempio, se si sta lavorando su WYSIWYG pagina web costruttore. documentazione adeguata di questo caso l'uso in genere non disponibili. Ci sono molti punti in cui si deve sperimentare e lo sviluppo è tranquillo lento. Molte cose non funzionano come ci si aspetterebbe. Ma in generale la sua possibile mod in qualche modo.
Cosa buona è che non è problema in filosofia o architettura del JSF. Non è semplicemente elaborato abbastanza (per quanto ne so).

JSF 2 portato Composite Components che dovrebbe rendere lo sviluppo di componenti facile, ma il loro sostegno per la costruzione dinamica (programmatico) è molto povera. Se a superare tranquilla complicato e processo quasi privi di documenti di dinamica di costruzione Composite Component, troverete che se si nido pochi componenti compositi po 'più profonda, che smettono di funzionare, gettando alcune eccezioni.

Ma sembra che la comunità JSF è consapevole di questo carenze. Stanno lavorando su questo, come si può vedere da questi due insetti
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

Situazione dovrebbe essere meglio con JSF 2.2 almeno se stiamo parlando di specifica.

Nel commentare i miei ultimi mesi di esperienza primefaces / JSF:

  • Se è possibile utilizzare i componenti "off the shelf", immagino che non è terribile.
  • Tuttavia, non gioca bene, non appena si esce e necessità interfacce utente personalizzate. - Per esempio, abbiamo bisogno di usare bootstrap di Twitter per il nostro progetto. (Non primefaces bootstrap).
    • Ora nostre pagine funzionano come segue:
      • caricamento della pagina.
      • interagisce utente con un primefaces che ha Ajax funzionalità
      • di Sputafuoco attacchi JavaScript pausa
      • Corriamo javascript in più per rebind tutto

La promessa di JSF di evitare di scrivere javascript nella scrittura più javascript che avremmo se non si utilizza primefaces -. E che javascript per correggere ciò che è primefaces pause

E 'un lavandino di tempo - a meno che non si utilizza di nuovo "off the shelf" roba. Anche veramente brutto (primefaces) quando dover lavorare con selenio. Tutto può essere fatto - ma ancora una volta -. C'è solo così tanto tempo

Sicuramente evitare questo se si sta lavorando con un / team di progettazione UX e necessità di rapida iterate sulla UI - è possibile risparmiare tempo, imparando jquery / scrittura diritta HTML - o guardando reagire / angolare.

JSF ha molti vantaggi, domanda di essere in svantaggio permettetemi di aggiungere paio di punti su di esso.

In uno scenario di pratica di realizzazione di un progetto web con in un lasso di tempo è necessario tenere d'occhio i seguenti fattori.

  • Avete abbastanza alti membri della tua squadra che può suggerire migliore controlli adeguati per ogni scenario?

  • Avete la larghezza di banda per ospitare la curva di apprendimento iniziale?

  • Avete abbastanza esperienza nel vostro team che può rivedere il JSF
    roba produce dagli sviluppatori?

Se la vostra risposta è 'No' per le domande, si può finire in una base di codice non mantenibile.

JSF ha un solo svantaggio:. Prima di iniziare lo sviluppo "JSF" si dovrebbe capire chiaramente lo sviluppo web, java core e architettura front-end

Al giorno d'oggi "nuovo" framework JavaScript cercano solo di copiare / incollare il modello basato su componenti "JSF".

Tra tutti i quadri "tradizionali" come Spring MVC, Wicket, arazzo, ecc, il JSF di Java EE con i suoi componenti in composito è la presentazione-strato più elaborato e tecnologia del componente orientata fornito. Si tratta di un ingombrante bit e incompleto rispetto alle soluzioni fornite da HybridJava.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top