Allow me to throw in a vote for Sitemesh. I've never used Tiles, so I can't directly compare the two, but Sitemesh is quite easy to use and incredibly powerful for this sort of thing. You define it as a servlet filter in your project, and it adds decoration to the requests that come through. The JSPs never even have to know that they're being decorated in the first place!
-Brian On Tue, Jun 22, 2010 at 1:35 PM, satyanarayana katta <saty.pra...@gmail.com> wrote: > U should try tiles for this > > Sent from my iPhone > > On Jun 22, 2010, at 10:03 AM, "Antonio S." <inganto...@gmail.com> wrote: > >> Hello. >> >> I'm a beginner in web development with Struts2 and I'm planning the >> structure of my application. Let me tell you my problem. >> >> With 'page composition strategy' I mean the strategy for making all >> pages in the application share the same HTML structure (header, >> left-column, content, right column, footer) using template inclusion >> mechanisms or others. >> >> Currently I'm using inclusion and all my JSPs share the same structure: >> >> A. 'include' prelude content: header, left-column. >> B. Specific content. >> C. 'include' coda content: right-column, footer. >> >> I don't like this approach and I'm thinking about alternatives; I wonder >> if Struts2 can help with this: >> >> i. Use the very same JSP template for all requests. That template would >> include specific content by calling the corresponding segment. This >> would involve a default result pointing to this JSP template and some >> means of specifying the name of the specific segment that will be >> invoked from inside the main template. >> >> ii. Use result pages as segments and render only specific content. Later >> on, some interceptor or servlet filter would include prelude and coda in >> the output stream. >> >> So, my questions are: >> >> 1. Can you recommend the best practice for page composition in Struts2? >> 2. Can I use Struts2 for implementing above mentioned strategies i. and >> ii.? How? >> >> Thanks for your time. >> Regards. >> Antonio. >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
