Perché utilizzare un motore di template? jsp include e jstl vs piastrelle, freemarker, velocità, sitemesh

Sto per scegliere il modo di organizzare il mio punto di vista (con spring-mvc, ma che non dovrebbe interessare più di tanto)

Ci sono 6 opzioni per quanto vedo io (anche se non sono mutuamente esclusivi):

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

Piastrelle e Sitemesh possono essere raggruppati; così può Freemarker e Velocità. Di cui uno all’interno di ogni gruppo non è argomento di questa discussione, ci sono abbastanza domande e discussioni su di essa.

Questa è una lettura interessante, ma non riesco a convincere me di utilizzare piastrelle.

La mia domanda è: – che cosa questi quadri di danno che non può essere fatto correttamente con <@ include file=".."> e JSTL. Punti principali (alcune scattate dall’articolo):

  1. Comprese le parti di pagine, come l’intestazione e il piè di pagina – non c’è una differenza tra:
    <%@ include file="header.jsp" %>

    e

    <tiles:insert page="header.jsp" />
  2. Definizione dei parametri nell’intestazione – come title, meta tag, ecc. Questo è molto importante, soprattutto dal SEO punto di vista. Con il template di opzioni che si possono definire semplicemente un segnaposto che ogni pagina deve definire. Ma così jsp con JSTL, utilizzando <c:set> (in cui) e <c:out> (nella pagina inclusa)
  3. Layout di riorganizzazione – se si desidera spostare la barra di navigazione sopra il menu, o il login casella sopra l’altro lato del pannello. Se la pagina di inclusioni (con jsp) non è ben organizzato, potrebbe essere necessario modificare ogni singola pagina in tali casi. Ma se il layout non è eccessivamente complessa, e metti le cose comuni in intestazione/piè di pagina, non c’è nulla di cui preoccuparsi.
  4. Accoppiamento tra i componenti comuni e i contenuti specifici – non trovo un problema con questo. Se si desidera riutilizzare qualche frammento, per spostare una pagina che non comprende l’eventuale intestazione/piè di pagina e ovunque sia necessario.
  5. Efficienza<%@ include file="file.jsp" %> è più efficiente di qualsiasi altra cosa, perché è compilato una sola volta. Tutte le altre opzioni sono analizzati/eseguito molte volte.
  6. Complessità – non-jsp soluzioni richiedono ulteriori file xml, ulteriori include, pre-processore configurazioni, etc. Questo è sia una curva di apprendimento e l’introduzione di ulteriori potenziali punti di rottura. Inoltre, rende il supporto e la modifica di più noioso – è necessario controllare un numero di file e configurazioni per capire cosa sta succedendo.
  7. Segnaposto – fare velocità/freemarker dare qualcosa di più di JSTL? In JSTL si mette segnaposto, e utilizzare il modello (inserito nella richiesta o scope di sessione, dal controller) per riempire questi segnaposto.

Così, mi convincono che dovrei usare uno qualsiasi dei suddetti quadri invece di/in aggiunta alla normale JSP.

  • Non so esattamente come mi piacerebbe confrontare, dai sto usando Strisce di modelli di layout per un po ‘ e trovo che è molto più bello di pianura JSP. Faccio uso di alcune jsp:include chiamate, ma questi sono in genere abbastanza casi particolari. Il modello di layout meccanismo è davvero comodo e potente strumento.
  • sì, ho sentito che tutti questi sono “comodo e potente”, ma non l’ho visto. Quello che ho visto, però è inutili complessità e mucchi di file di configurazione. (Non sto parlando di strisce in particolare, ma in generale)
  • Vedi anche stackoverflow.com/questions/610062/…
  • Credo jsp:include è abbastanza efficiente – è compilato in una chiamata al metodo dall’tra cui servlet inclusi. Essa si traduce in meno codice generato di @include, che possono anche migliorare le prestazioni a causa della cache effetti.
  • StringTemplate sviluppatore rende il miglior argomento ho visto che è molto simile a regola di minor potenza
  • Ancora un altro modello di motore compatibile con Spring-MVC: Thymeleaf. (thymeleaf.org) probabilmente Si dovrebbe iniziare ad arrotolare un dado per determinare che TE la vostra intenzione di utilizzare.

InformationsquelleAutor Bozho | 2010-07-02

 

7 Replies
  1. 17

    Alcuni argomenti per la Velocità (non ho usato Freemarker):

    • Potenziale di ri-utilizzare modelli al di fuori di un contesto web, come ad esempio l’invio di messaggi di posta elettronica
    • Velocità del modello: la sintassi del linguaggio è lontano più semplice di JSP, EL o librerie di tag
    • Rigorosa separazione di vista logico da qualsiasi altro tipo di logica – non è una possibile opzione per la discesa a utilizzare scriptlet tag e fare le cose brutte nel template.

    Segnaposto – fare velocità/freemaker dare qualcosa di più di JSTL? In JSTL si mette segnaposto, e utilizzare il modello (inserito nella richiesta o scope di sessione, dal controller) per riempire questi segnaposto.

    Sì, riferimenti sono davvero il nucleo 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é è compilato una sola volta. Tutte le altre opzioni sono analizzati/eseguito molte volte.

    Non è così sicuro sono d’accordo con o capire questo punto. La velocità è un’opzione per memorizzare nella cache i modelli, il che significa l’albero di sintassi astratta sono analizzate in verrà memorizzata nella cache invece di leggere dal disco ogni volta. In entrambi i modi (e non ho solido numeri per questo), la Velocità è sempre e solo sentito veloce per me.

    Layout di riorganizzazione – se si desidera spostare la barra di navigazione sopra il menu, o il login casella sopra l’altro lato del pannello. Se la pagina di inclusioni (con jsp) non è ben organizzato, potrebbe essere necessario modificare ogni singola pagina in tali casi. Ma se il layout non è eccessivamente complessa, e metti le cose comuni in intestazione/piè di pagina, non c’è nulla di cui preoccuparsi.

    La differenza, con una JSP approccio, non sarebbe ri-organzing questo layout in ogni file JSP che utilizza la stessa intestazione/piè di pagina? Piastrelle e SiteMesh consentono di specificare un layout di base pagina JSP (Velocità, modello, ecc – entrambi sono JSP quadri al loro cuore) in cui è possibile specificare quello che vuoi e poi delegare ad un “contenuto” frammento/modello per il contenuto principale. Questo significa che non ci sarebbe un solo file per spostare l’intestazione.

    • la velocità esempi si danno può essere fatto facilmente con JSTL. con il punto di efficienza voglio dire che le jsp sono compilate in servlets, e nulla viene analizzato. Ma la cache di modelli è anche una buona soluzione, sì. come per la riorganizzazione – no, io di solito modulo, che comprende, in un modo devo solo modificare la comprende, non la “includers”. Forse in casi più complessi, questo non è possibile.
    • Oltre il riutilizzo di modelli fuori del contesto web, la Velocità consente di ottenere facilmente il rendering della pagina web prima della visualizzazione per il cliente. È utile quando si desidera rendere il vostro sito per essere generato come file HTML. Con JSP – non facile soluzione. Questo è stato il motivo principale per cui siamo passati a Velocità da JSP. Una questione di velocità, ho fatto un po ‘ di benchmarking e Velocità di rendering delle pagine esattamente 2 volte più veloce di JSP. Quindi la velocità non è un problema. Ora, dopo aver trascorso con Velocità di pochi anni non sarà mai tornare indietro per JSP di nuovo. È molto più semplice, più leggero e più pulito.
    • non si dispone di tali parametri di riferimento pubblicato da nessuna parte? Mi piacerebbe vedere altri dati su questo. Sarei interessato a vedere come è stato eseguito il benchmark troppo. Credo che questo sarebbe una buona info per gli altri meditando la stessa “Velocità vs JSP vs altri motori” domanda.
    • Non ho i risultati pubblicati. Appena ho convertiti in diverse pagine del nostro sito e misurato il tempo di rendering prima e dopo. Niente di troppo scientifico 🙂
    • qual è stata la piattaforma/servlet container/versione di jsp ?
    • winxp/tomcat 5.5/jsp 2.0. Circa 3 anni fa, forse somethign è cambiato in JSP mondo da allora.

  2. 11

    La scelta tra jsp:include e Piastrelle/Sitemesh/etc è la scelta tra semplicità e potenza che gli sviluppatori di fronte per tutto il tempo. Certo, se avete solo un paio di file o non aspettatevi un cambiamento del layout molto spesso, quindi basta usare jstl e jsp:include.

    Ma le applicazioni hanno un modo di crescere in modo incrementale, e può essere difficile da giustificare l’ “stop nuovo sviluppo e retrofit piastrelle (o qualche altra soluzione), in modo siamo in grado di risolvere problemi in futuro, più facilmente”, che è necessario se non si utilizza una soluzione complessa all’inizio.

    Se l’applicazione rimarrà sempre semplice, o è possibile impostare alcuni benchmark della complessità dell’applicazione, dopo di che si provvederà ad integrare una delle soluzioni più complesse, poi mi consiglia di non utilizzo di piastrelle/etc. In caso contrario, utilizzare dal get-go.

  3. 4

    Non ho intenzione di convincere l’utilizzo di altre tecnologie. Per tutti so che ognuno di noi dovrebbe solo attenersi a JSP se funziona per loro.

    Io lavoro principalmente con Spring MVC e trovo JSP 2+ in combinazione con SiteMesh la partita perfetta.

    SiteMesh 2/3

    Fornire decoratori per essere applicato per il punto di vista per lo più come eredità opere in altri motori di template. Tale caratteristica è impensabile lavorare senza oggi.

    JSP 2+

    Persone che affermano che JSP sarà difficile evitare di codice Java in modelli è falso. Basta non farlo e con questa versione è inutile farlo. Versione 2 supporta la chiamata di metodi di utilizzo di EL che è un grande vantaggio rispetto alle versioni precedenti.

    Con JSTL tag il codice sarà ancora l’aspetto di HTML, quindi è meno imbarazzante. Primavera confezioni un sacco di supporto per JSP attraverso taglibs che è molto potente.

    Il taglibs sono anche facili da estendere in modo personalizzare il proprio ambiente è un gioco da ragazzi.

    • Non vedo I vantaggi di SiteMesh. Tag Jsp di offrire la stessa decorazione funzionalità come SiteMesh, ma con una maggiore flessibilità, meno fragile di installazione, e mi piacerebbe ipotizzare una maggiore efficienza anche dal post-processo di analisi è coinvolto.
  4. 2

    Uno dei migliori argomenti per facelets (non nel tuo elenco, ma mi limiterò a menzionare) anziché utilizzare JSP è che la compilazione è integrato con l’interprete, invece di essere delegato al compilatore JSP. Questo significa che una delle cose più fastidiose che ho avuto con il JSF 1.1 – dover cambiare l’id attributo circostante JSF-tag per il salvataggio di un cambiamento in modo che il motore di runtime per scoprire il cambiamento – è andato via, mi salva-in-editor di ricarica-in-browser ciclo, molto meglio i messaggi di errore.

    • Sì, per il JSF, facelets è soluzione solo grazie alla stretta integrazione con l’interprete. Ma qui non è questo il caso 🙂
    • Ho appena accennato, nel caso in cui uno di questi aveva la stessa funzione, che sarebbe un elemento decisivo per me.
  5. 2

    Una buona vista della tecnologia elimina la maggior parte e più anoying if/switch/istruzioni condizionali, semplice includono non. Utilizzando un ‘complesso’ di visualizzazione dei risultati della tecnologia in un ‘semplice’ applicazione.

  6. 1

    Non fornire informazioni sulle specifiche delle applicazioni. Per esempio io non uso JSP, solo per pochi motivi:

    È difficile evitare l’uso di codice Java JSP modelli, così la vostra pausa concetto di pura Vista, e come risultato si avrà difficoltà a mantenere il codice in diversi luoghi, come la vista e il controller

    JSP crea automaticamente JSP contesto che stabilisce una sessione. Mi potrebbe essere utile per evitare, tuttavia, se le vostre applicazioni sempre usare la sessione può non essere un problema per voi

    JSP richiede la compilazione e se il sistema di destinazione non dispone di un compilatore Java, eventuali piccoli aggiustamenti si richiede l’uso di un altro sistema e quindi ridistribuire

    Minimo motore di JSP è di circa 500k di bytecode plus JSTL, quindi può non essere adatto per sistemi embedded

    Modello di motore in grado di generare diverso tipo di contenuto dello stesso modello, diciamo payload JSON, pagina web, e-mail, CSV e così via.

    Non di programmazione Java e può avere difficoltà a lavorare con JSP modelli, quando non tecnica la gente non ha mai avuto difficoltà a modificare i modelli di regolari.

    Stavo chiedendo la stessa domanda tempo fa e terminato di scrivere il mio quadro (sicuramente modello motore di base) che era esente da tutti gli svantaggi che ho visto in altre soluzioni. Inutile dire che si tratta di circa 100k di byte di codice.

  7. 0

    Mi rendo conto che questo viene fuori come un culo intelligente risposta, ma la verità è che se non si vede alcun vantaggio nell’utilizzo di template sul codice nell’attuale progetto, è probabilmente perché nell’attuale progetto, non c’è.

    Parte di esso è di circa scala. Si potrebbe pensare che include ogni bit come potente come diciamo sitemesh, ed è sicuramente vero, almeno per un piccolo numero di pagine (direi che probabilmente su 100), ma se si dispone di diverse migliaia si comincia a diventare ingestibile. (Così, per eBay non è necessario, per la Salesforce probabilmente lo è)

    Anche, come è stato detto prima, freemarker e la velocità non sono servlet specifici. si possono usare per qualsiasi cosa (modelli di posta, documentazione non in linea, etc.). Non hai bisogno di un Servlet container per uso freemarker o la velocità.

    Infine il punto 5, è vero solo in parte. Viene compilato ogni volta che vi si accede se non è stato così già. Questo significa che ogni volta che si cambia qualcosa, bisogna ricordarsi di eliminare il servlet container “lavoro” directory, in modo che si ricompila il JSP. Questo non è necessario con un motore di template.

    TL;DR Templaing motori sono stati scritti per affrontare alcune (reale o percepito) carenze di JSP + JSTL. Se si deve utilizzare o meno dipende interamente dalle vostre esigenze e la scala del tuo progetto.

Lascia un commento