Perché dovrei usare un motore di modelli? jsp include e jstl vs tiles, freemarker, velocity, sitemesh

Sto per scegliere come organizzare la mia vista (con spring-mvc, ma non dovrebbe importare molto)

Ci sono 6 opzioni per quanto vedo (anche se non si escludono a vicenda):

• Piastrelle
• Sitemesh
• Freemarker
• Velocità
• <jsp:include>
• <%@ include file="..">

Le tessere e le Sitemesh possono essere raggruppate; così possono Freemarker e Velocity . Quale all'interno di ogni gruppo usare non è oggetto di questa discussione, ci sono abbastanza domande e discussioni al riguardo.

Questa è una lettura interessante , ma non riesco a convincermi a usare le tessere.

La mia domanda è: cosa danno questi framework che non può essere fatto correttamente con <@ include file=".."> e JSTL. Punti principali (alcuni tratti dall'articolo):

1. Includendo parti di pagine, come intestazione e piè di pagina , non c'è differenza tra:

   <%@ include file="header.jsp" %>

   e

   <tiles:insert page="header.jsp" />

2. Definizione dei parametri nell'intestazione - come titolo, meta tag, ecc. Questo è molto importante, soprattutto dal punto di vista SEO. Con le opzioni di template puoi semplicemente definire un segnaposto che ogni pagina dovrebbe definire. Ma così puoi in jsp con JSTL , usando <c:set>(nella pagina inclusa) e <c:out>(nella pagina inclusa)

3. Riorganizzazione del layout : se desideri spostare il breadcrumb sopra il menu o la casella di accesso sopra un altro pannello laterale. Se le inclusioni di pagina (con jsp) non sono ben organizzate, potrebbe essere necessario modificare ogni singola pagina in questi casi. Ma se il tuo layout non è eccessivamente complesso e metti le cose comuni nell'intestazione / piè di pagina, non c'è nulla di cui preoccuparsi.

4. Accoppiamento tra i componenti comuni e il contenuto specifico : non trovo un problema con questo. Se desideri riutilizzare un frammento, spostalo in una pagina che non include intestazioni / piè di pagina e includilo dove necessario.

5. Efficienza : <%@ include file="file.jsp" %>è più efficiente di qualsiasi altra cosa, perché viene compilato una volta. Tutte le altre opzioni vengono analizzate / eseguite molte volte.

6. Complessità : tutte le soluzioni non jsp richiedono file xml aggiuntivi, include aggiuntivi, configurazioni pre-processore, ecc. Questa è sia una curva di apprendimento che introduce più potenziali punti di errore. Inoltre, rende il supporto e la modifica più noiosi: devi controllare una serie di file / configurazioni per capire cosa sta succedendo.

7. Segnaposto : velocità / freemarker danno qualcosa in più di JSTL? In JSTL si inserisce un segnaposto e si utilizza il modello (inserito nell'ambito della richiesta o della sessione, dai controller) per riempire questi segnaposto.

Quindi, convincimi che dovrei usare uno qualsiasi dei framework sopra invece di / in aggiunta al semplice JSP.

Alcuni argomenti per Velocity (non ho usato Freemarker):

• Possibilità di riutilizzare i modelli al di fuori di un contesto web, ad esempio per l'invio di e-mail
• La sintassi del linguaggio dei modelli di Velocity è molto più semplice di JSP EL o delle librerie di tag
• Rigorosa separazione della logica di visualizzazione da qualsiasi altro tipo di logica: nessuna opzione possibile per passare all'uso dei tag scriptlet e fare cose brutte nei modelli.

Segnaposto: velocity / freemaker offre qualcosa di più del JSTL? In JSTL si inserisce un segnaposto e si utilizza il modello (inserito nell'ambito della richiesta o della sessione, dai controller) per riempire questi segnaposto.

Sì, i riferimenti sono davvero il cuore di VTL:

<b>Hello $username!</b>

o

#if($listFromModel.size() > 1)
    You have many entries!
#end

Efficienza: <%@ include file="file.jsp" %>è più efficiente di qualsiasi altra cosa, perché viene compilato una volta. Tutte le altre opzioni vengono analizzate / eseguite molte volte.

Non sono così sicuro di essere d'accordo o di capire questo punto. Velocity ha un'opzione per memorizzare i modelli nella cache, il che significa che l'albero della sintassi astratto in cui vengono analizzati verrà memorizzato nella cache anziché letto dal disco ogni volta. Ad ogni modo (e non ho numeri solidi per questo), Velocity si è sempre sentito veloce per me.

Riorganizzazione del layout: se desideri spostare il breadcrumb sopra il menu o la casella di accesso sopra un altro pannello laterale. Se le inclusioni di pagina (con jsp) non sono ben organizzate, potrebbe essere necessario modificare ogni singola pagina in questi casi. Ma se il tuo layout non è eccessivamente complesso e metti le cose comuni nell'intestazione / piè di pagina, non c'è nulla di cui preoccuparsi.

La differenza è che, con un approccio JSP, non vorresti riorganizzare questo layout in ogni file JSP che utilizza la stessa intestazione / piè di pagina? Tiles e SiteMesh ti consentono di specificare una pagina di layout di base (JSP, modello Velocity, ecc. - entrambi sono framework JSP al centro) dove puoi specificare quello che vuoi e quindi delegare semplicemente a un frammento / modello di "contenuto" per il contenuto principale . Ciò significa che ci sarebbe un solo file in cui spostare l'intestazione.

La scelta tra jsp:includee Tiles / Sitemesh / etc è la scelta tra semplicità e potenza che gli sviluppatori devono affrontare in ogni momento. Certo, se hai solo pochi file o non ti aspetti che il tuo layout cambi molto spesso, allora usajstl e jsp:include.

Ma le applicazioni possono crescere in modo incrementale e può essere difficile giustificare il "l'interruzione del nuovo sviluppo e il retrofit di piastrelle (o qualche altra soluzione) in modo da poter risolvere i problemi futuri più facilmente" , che è richiesto se non si utilizza un soluzione complessa all'inizio.

Se sei sicuro che la tua applicazione rimarrà sempre semplice, o puoi impostare un benchmark di complessità dell'applicazione dopo di che integrerai una delle soluzioni più complesse, allora ti consiglio di non usare tiles / etc. Altrimenti, usalo dall'inizio.

Non ti convincerò a usare altre tecnologie. Per quanto ne so, tutti dovrebbero attenersi a JSP se funziona per loro.

Lavoro principalmente con Spring MVC e trovo JSP 2+ in combinazione con SiteMesh la soluzione perfetta.

SiteMesh 2/3

Fornire decoratori da applicare alle viste principalmente come opere di eredità in altri motori di modelli. Tale caratteristica è impensabile al giorno d'oggi lavorare senza.

JSP 2+

Le persone che affermano che JSP renderà difficile evitare il codice Java nei modelli è fasullo. Non dovresti farlo e con questa versione non è necessario farlo. La versione 2 supporta i metodi di chiamata utilizzando EL che è un grande vantaggio rispetto alle versioni precedenti.

Con i tag JSTL il codice apparirà ancora come HTML, quindi è meno scomodo. Spring racchiude molto supporto per JSP attraverso taglib che è molto potente.

I taglib sono anche facili da estendere, quindi personalizzare il tuo ambiente è un gioco da ragazzi.

Uno dei migliori argomenti per i facelets (non nella tua lista, ma lo menzionerò solo) che si oppongono all'uso di JSP è che la compilazione è integrata con l'interprete invece di essere delegata al compilatore JSP. Ciò significa che una delle cose più fastidiose che ho avuto con JSF 1.1 - dover cambiare l'attributo id su un tag JSF circostante quando si salva una modifica in modo che il motore di runtime possa scoprire la modifica - è andata via, dando il salvataggio- nell'editor, ricarica nel browser torna indietro, insieme a messaggi di errore molto migliori.

Una buona tecnologia di visualizzazione elimina la maggior parte e la maggior parte delle affermazioni if ​​/ switch / condizionali, il semplice include no. Utilizzando una tecnologia di visualizzazione "complessa" si ottiene un'applicazione "semplice".

Non hai fornito informazioni su specifiche delle tue applicazioni. Ad esempio, non utilizzo JSP solo per alcuni motivi:

È difficile evitare di utilizzare il codice Java nei modelli JSP, quindi il tuo concetto di interruzione della visualizzazione pura e, di conseguenza, avrai difficoltà a mantenere il codice in diversi punti come visualizzazione e controller

JSP crea automaticamente il contesto JSP che stabilisce una sessione. Potrei volerlo evitare, tuttavia se le tue applicazioni usano sempre la sessione, non può essere un problema per te

JSP richiede la compilazione e se il sistema di destinazione non ha il compilatore Java, qualsiasi modifica minore richiederà l'utilizzo di un altro sistema e quindi la ridistribuzione

Il motore JSP minimo è di circa 500k di bytecode più JSTL, quindi potrebbe non essere adatto per i sistemi embedded

Il motore del modello può generare diversi tipi di contenuto dello stesso modello, diciamo payload JSON, pagina web, corpo dell'e-mail, CSV e così via.

I programmatori non Java potrebbero avere difficoltà a lavorare con i modelli JSP, quando i non tecnici non hanno mai avuto difficoltà a modificare i modelli regolari.

Stavo facendo la stessa domanda molto tempo fa e ho finito per scrivere il mio framework (sicuramente basato su template engine) che era privo di tutti gli svantaggi che vedevo in altre soluzioni. Inutile dire che si tratta di circa 100k di byte code.

Mi rendo conto che questa viene fuori come una risposta intelligente, ma la verità è che se non vedi alcun vantaggio nell'usare la creazione di modelli sul codice nel tuo progetto corrente, è probabilmente perché nel tuo progetto attuale non ce n'è uno .

Parte di esso riguarda la scala. Potresti pensare che gli include siano potenti quanto diciamo sitemesh, e questo è certamente vero, almeno per un piccolo numero di pagine (direi probabilmente circa 100), ma se ne hai diverse migliaia inizia a diventare ingestibile. (Quindi per eBay non è necessario, per Salesforce probabilmente lo è)

Inoltre, come è stato accennato prima, il freemarker e la velocità non sono specifici del servlet. puoi usarli per qualsiasi cosa (modelli di posta, documentazione offline, ecc.). Non è necessario un contenitore Servlet per utilizzare freemarker o velocità.

Infine il tuo punto 5 è solo parzialmente vero. Viene compilato ogni volta che vi si accede se non lo è già stato. Ciò significa che ogni volta che si modifica qualcosa è necessario ricordarsi di eliminare la directory "lavoro" dei contenitori servlet, in modo che ricompili il JSP. Questo non è necessario con un motore di modelli.

TL; DR Templaing engine sono stati scritti per risolvere alcune carenze (percepite o reali) di JSP + JSTL. Che tu debba usarli o meno dipende interamente dalle tue esigenze e dalle dimensioni del tuo progetto.