2012-02-25 10 views
5

Tiles e Sitemesh sono piuttosto popolari, ma questa roba è davvero vecchia e sembra terribile se paragonata alle attuali cose fantastiche, ad es. Ruby (ERB) o PHP (Open Power Template). I motori di template di questi giorni consentono un comodo template (inserimento di variabili, autoescaping a seconda del contesto, iterazione attraverso Iterables, accesso alle proprietà bean) e layout (ad es. Intestazioni, footer e override e aggiunta ad alcune parti definite in parent) senza alcuna configurazione difficile e senza wihout bisogno di cambiare il tuo stack attuale (es. il tuo framework web).JSP, sitemesh e piastrelle hardcore: tutte le alternative?

Esempio Parent.html:

<html> 
    <head> 
    <title> 
     <layout:part name="title"> 
     Default title 
     </layout:part> 
    </title> 
    <layout:part name="head" /> 
    </head> 
    <body> 
    <div class="menu" layout:part="menu"> 
     default menu 
    </div> 
    <div class="content" layout:part="content" /> 
    <div class="footer"> 
     (c) me 
    </div>  
    </body> 
</html> 

Esempio child.html

<layout:extend file="parent.html"> 
    <layout:fill name="title"> 
    Custom title 
    </layout:fill> 
    <layout:fill name="contnet"> 
    the content 
    {$var} from model 
    </layout:fill> 
</layout:extend> 

sto cercando Facelets migliori, che non mi richiede di cambiare l'intero stack - Sono non adatterà l'intero progetto a JSF o Wicket solo per utilizzare viste migliori.

Il motore di template non dovrebbe richiedere alcun servlet o filtro aggiuntivo (nessuna logica basata su URL). Voglio usare il motore programmaticamente. Un possibile caso d'uso è la definizione di un ViewResolver personalizzato nella primavera 3.

Sarebbe perfetto se i layout non fossero definiti in primo piano in un file di configurazione. Non è necessario se si definisce la vista genitore nel file di modello.

Il framework può essere in cima a JSP ma non è necessario. Il vantaggio è la possibilità di utilizzare i tagli forniti da altri quadri (ad esempio la primavera).

O forse tutto è già presente in Sitemesh/Tiles ma necessita di molte configurazioni? Se sei a conoscenza di una configurazione di esempio che consente di raggiungere tutti gli obiettivi citati, fammelo sapere.

Domande correlate: what alternatives exist to Sitemesh to help layout JSP/JSTL page footers/headers in a Spring MVC app? - la mia domanda si riferisce anche ai modelli e non è limitata a Spring Web MVC.

+0

Perché secondo te Tiles 2 è vecchio stile? Ho appena trascurato ERB, ma sembra che tu possa ottenere le stesse caratteristiche usando Tiles 2 e Velocity, per esempio. Di che cosa hai bisogno? – sinuhepop

+0

Chiedere suggerimenti quadro è scoraggiato qui. Se si desidera [modificare] tutte le richieste per tale, e rendere questa una domanda che può essere risolta qui senza fare clic fuori dal sito, si prega di farlo e contrassegnare per la riapertura. Grazie. – Will

risposta

3

devo sempre supported the idea that JSP is a good-enough view technology che è anche utilizzabile per i modelli (utilizzando include)

Per la movimentazione di programmazione che uso velocità, che è piuttosto semplice e lineare.

La migliore tecnologia di visualizzazione che ho incontrato nel mondo Java è GSP di Grails, ma potrebbe essere necessario migrare l'intero livello Web in Grails, che non è sempre un'opzione.

Solo una nota finale: qualunque cosa tu faccia, non usare freemarker. È inutilmente complicato e non è possibile ottenere facilmente compiti semplici.

+2

Ho letto questo prima. Devo ammettere che avere uno stack complicato composto da Sitemesh, Tiles, Velocity e molti file di configurazione non va bene. Tuttavia, le JSP semplici non ti aiutano con il layout e sono piuttosto deboli con i template. Essendo abituato ai buoni motori di template di Ruby, PHP, è piuttosto frustrante non avere l'equivalente in Java - lo stack su cui lavoro la maggior parte delle volte. :( – Nowaker

+1

grails è buono per questo - (g) rotaie – Bozho

+3

Questo è tutto lo stack.Non riesco a vedere un motivo per cui gli sviluppatori dovrebbero migrare il progetto esistente in JSF solo per usare Facelets, per Grails solo per usare GSP e così via. – Nowaker