struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zaunick" <>
Subject AW: Application layout pattern?
Date Tue, 28 Aug 2001 07:33:53 GMT
No, not really.
The Resin server can cache pages by acting like a proxy server. 
It uses the GET parameters of the HTTP request to distinguish different
page requests. 
Template parameters are passed as request attributes not as parameters,
making it impossible to be cached at the application server layer.

-----Ursprungliche Nachricht-----
Von: []Im Auftrag
von Craig R. McClanahan
Gesendet: Dienstag, 28. August 2001 02:46
Betreff: Re: Application layout pattern?

Check out the "template" tag library included inStruts.  It addresses
these sorts of application layout issues.


On Tue, 28 Aug 2001, Kai Zaunick wrote:

> Date: Tue, 28 Aug 2001 02:13:09 +0200
> From: Kai Zaunick <>
> Reply-To:
> To:
> Subject: Application layout pattern?
> Hi all,
> in an application you often have a general layout, e.g. menu bar to the
> left, header on top and a content section. Now, lets say you would
> define an action which displays threads in a message forum.
> Naturally you would define some subclass of Action which forwards
> the result to a jsp page lets say displayThread.jsp. Instead of building
> the site layout on every jsp page like displayThread.jsp (...editMessage.jsp, etc.)
> you could have a centralized Action building the general application layout
> which then includes the displayThread action in the content section with jsp:include.
> The jsp:include would actually pass on the params needed for the displayThread action
> which will (hopefully) result in the displayThread.jsp.
> General ideas:
> 1. Centralized Action which builds the overall application layout and forwards control
>    to real Action classes which do the work.
>    (sounds actually like a second level controller)
> 2. By using the jsp:include tag enabling caching mechanisms used with the resin server.
> Now my question:
> Is this a good approach/ common "struts design pattern" or do you have a different/
> better approach?

View raw message