java web app decorazione / include problemi

Question

Background: abbiamo un sistema che è stato scritto in un vecchio CMS basato su Java nei giorni 2002-2003. Vogliamo continuare ad andare avanti con le nostre nuove cose, usando tomcat, strisce e sitemesh. Abbiamo navigazione, layout, & Quot; pods & Quot ;, js, css, ecc., Che abbiamo rimosso dal vecchio CMS e in alcune delle nostre nuove app in modo da avere un aspetto coerente.

Ora abbiamo bisogno di una sorta di soluzione per sbarazzarci di tutta la duplicazione del codice in corso. Le nostre app sono attualmente in esecuzione sulla stessa VM, ma ciò potrebbe cambiare. Abbiamo bisogno di un modo per tutte le nostre istanze di Tomcat di accedere ad alcuni elementi comuni (e tali elementi potrebbero / potrebbero non dover eseguire alcune operazioni sul lato server).

Il meglio che abbiamo trovato finora è creare un decoratore di sitemesh abbastanza standard, che usa c: import per ottenere ciò di cui ha bisogno e lo collega direttamente. Questa soluzione ha un overhead di rete che potrebbe impantanarlo e introdurre un punto di errore. Abbiamo esaminato & Lt;% @ include file = & Quot; /something.jsp & Quot; % Gt &; anche ma sembra essere solo un contesto relativo. Potremmo usare c: import e puntarlo a localhost, che finora sembra essere la soluzione migliore.

Esistono altri modelli di templating / decorating là fuori (Piastrelle?) che potrebbero rendere questo più semplice? Cosa ci manca?

Answer 1

Non sono del tutto sicuro di cosa stai cercando di fare qui. La mia interpretazione è questa: hai un numero di risorse che desideri riutilizzare in diverse app. Non vuoi duplicare questi file in tutte le app, in quanto renderebbe difficile mantenere la coerenza tra le app.

Se questa è la tua domanda, ti suggerirei di conservare le tue risorse comuni nei file jar. Ciò offre numerosi vantaggi:

1. Le tue risorse sono locali - nessun overhead di rete
2. Hai il controllo sugli aggiornamenti delle risorse.

Un esempio di nr 2: mantieni i tuoi layout di pagina comuni in page-layouts-1.x.jar. Continui a creare versioni secondarie dei layout di pagina che non influiscono sulle app che lo utilizzano: sono sostituzioni drop-in. Un giorno, decidi di riprogettare completamente le tue app e rilasciare page-layouts-2.0.jar. Ciò richiede alcune riscritture per le app che lo utilizzano. Ora, se le app raggruppano i layout di pagina, invece di tenerli in un caricatore di classi condiviso sul server, la migrazione al layout 2.0 non è una questione del tutto o niente. Puoi migrare un'app alla volta per usare il layout 2.0, mentre le altre usano ancora il layout 1.x.

Lo stiamo facendo con molto successo, usando JSF e Facelets.

Potresti dare un'occhiata a Weblet . Non ho idea se SiteMesh o Tiles abbiano ottenuto alcun supporto diretto per servire risorse dal percorso della classe, ma presumo che tu possa modificarle per farlo.

Spero che sia d'aiuto

Answer 2

Abbiamo usato Sitemesh per anni e ho sentimenti contrastanti al riguardo.

Preferisco di gran lunga scrivere file di tag JSP standard (.tag o .tagx) da usare di applydecorator. Penso che il tag applydecorator sia effettivamente obsoleto con l'avvento dei file tag, ma troppi utenti di Sitemesh non se ne sono accorti.

Quasi tutto il nostro utilizzo di Sitemesh è stato di questo tipo. Avremmo alcuni modelli di pagina comuni, che le nostre pagine JSP farebbero esplicitamente riferimento come layout. " Usa il layout standard, ecco il menu di navigazione ed ecco il corpo della pagina. " I file tag sono un duplicato esatto di questa funzionalità, ma sono standardizzati, supportati da qualsiasi strumento Web J2EE e integrati nel contenitore anziché in un'altra dipendenza.

Per decorare veramente una pagina, in cui la pagina JSP stessa non fa alcun riferimento a Sitemesh, penso che abbia senso a un livello elevato, ma ancora non mi piace che l'intera pagina venga analizzata di nuovo.

Questo secondo problema non è davvero colpa di Sitemesh; data l'API Servlet con cui deve funzionare, non so cos'altro potrebbe fare. Ma mi chiedo se un'alternativa basata su DOM all'API Servlet basata su stream potrebbe essere preziosa. In altre parole, anziché fare in modo che i servlet scrivano il loro output su uno stream, cosa succederebbe se aggiungessero nodi a un albero? Ciò importerebbe un output ben formato e renderebbe più economico eseguire trasformazioni strutturali come Sitemesh o codificherà l'output in diversi formati come XHTML, HTML o JSON al volo.