Performance of of action?

[Scott Cressler <sc...@propel.com>]

I'm trying to decide how to structure our app.  We want to use templates to
separate the layout from the content, and we want to use the Struts
framework to separate the business logic from the presentation.  I've been
converting several parts of our site and am happy with the results.
However, we also want to, as much as possible, separate out reusable parts
of the presentation into separate JSP pages (sort of "components").  For
example, we have a header and have it separated into header.jsp.  This JSP
page can take parameters and can also adjust itself based on its
"environment", that is, what it finds in the request.  But to do so, it has
a bunch of Java in the JSP (it was also developed before I came and without
an eye to keeping the business logic separate).

What I'd like to do is change the header.jsp to pull the Java out.  I see
several possible ways to do that.  One is to essentially develop an Action
that sets up for the JSP and then forwards to the JSP.  So, for example,
that would change the code in my current pages like:

<jsp:include page="/components/header.jsp" flush="true"><jsp:param
name="atab" value="main"/></jsp:include>

to look like:

<jsp:include page="/components/header.do" flush="true"><jsp:param
name="atab" value="main"/></jsp:include>

but I'm not sure what the performance implications of this would be.  That
is, what is the difference between a <jsp:include> of a JSP page versus an
Action.  In the case of the Action, it would be routed through the app
server (resin in our case...for now), through the ActionServlet and Action,
and then forwarded to the JSP.  (Now that I think of it, I'm not sure this
would even work, but I think it should.)  In the JSP case, is it also routed
through the app server, so the only difference is where the business logic
is done?

Another idea I have is to create one or more custom tags that will set up
for the header JSP.  That way, the JSP could be included just as header.jsp,
but the Java and business logic would have been extracted to the custom
tag(s).  The negative of this is it is a departure from the Struts
architecture and puts the business logic in a sort of unexpected place.

The last idea I had was to somehow cause the Action for the enclosing page
(that is, the page that does the <jsp:include> of the header) to do the
logic and setup necessary for the header.  Then the header would just get
what it needs from the request and could remain a JSP, not an Action.  The
negative of this is that the logic for the header would be performed by the
Actions of all the pages, although it could be included in the BaseAction
that I extend for my Actions.

BTW, we have one motivation that others may not have: we are developing an
example application that will be given to our customers to base their app
on.  So we want to structure things in the best, most understandable way.

Thanks for any help,
Scott

Re: Performance of of action?

[Cedric Dumoulin <ce...@lifl.fr>]

  I think there is no significant performance differences between "calling an
action", using <jsp:include> or using <template:insert>. Once the jsp page is
compiled, all these solutions result in java method calls.
  Differences are more on how you architect your jsp pages.
  As you speak of  'sort of components" in your mail, you may take a look to the
Components proposal, which can be seem as "extended templates", and will be
smoothly incorporated in Struts 1.1 .

    Cedric

Components sites :
  http://www.lifl.fr/~dumoulin/components/
  (mirror) : http://www.geocities.com/cedricdumoulin/components/




Scott Cressler wrote:

> I'm trying to decide how to structure our app.  We want to use templates to
> separate the layout from the content, and we want to use the Struts
> framework to separate the business logic from the presentation.  I've been
> converting several parts of our site and am happy with the results.
> However, we also want to, as much as possible, separate out reusable parts
> of the presentation into separate JSP pages (sort of "components").  For
> example, we have a header and have it separated into header.jsp.  This JSP
> page can take parameters and can also adjust itself based on its
> "environment", that is, what it finds in the request.  But to do so, it has
> a bunch of Java in the JSP (it was also developed before I came and without
> an eye to keeping the business logic separate).
>
> What I'd like to do is change the header.jsp to pull the Java out.  I see
> several possible ways to do that.  One is to essentially develop an Action
> that sets up for the JSP and then forwards to the JSP.  So, for example,
> that would change the code in my current pages like:
>
> <jsp:include page="/components/header.jsp" flush="true"><jsp:param
> name="atab" value="main"/></jsp:include>
>
> to look like:
>
> <jsp:include page="/components/header.do" flush="true"><jsp:param
> name="atab" value="main"/></jsp:include>
>
> but I'm not sure what the performance implications of this would be.  That
> is, what is the difference between a <jsp:include> of a JSP page versus an
> Action.  In the case of the Action, it would be routed through the app
> server (resin in our case...for now), through the ActionServlet and Action,
> and then forwarded to the JSP.  (Now that I think of it, I'm not sure this
> would even work, but I think it should.)  In the JSP case, is it also routed
> through the app server, so the only difference is where the business logic
> is done?
>
> Another idea I have is to create one or more custom tags that will set up
> for the header JSP.  That way, the JSP could be included just as header.jsp,
> but the Java and business logic would have been extracted to the custom
> tag(s).  The negative of this is it is a departure from the Struts
> architecture and puts the business logic in a sort of unexpected place.
>
> The last idea I had was to somehow cause the Action for the enclosing page
> (that is, the page that does the <jsp:include> of the header) to do the
> logic and setup necessary for the header.  Then the header would just get
> what it needs from the request and could remain a JSP, not an Action.  The
> negative of this is that the logic for the header would be performed by the
> Actions of all the pages, although it could be included in the BaseAction
> that I extend for my Actions.
>
> BTW, we have one motivation that others may not have: we are developing an
> example application that will be given to our customers to base their app
> on.  So we want to structure things in the best, most understandable way.
>
> Thanks for any help,
> Scott

Re: Performance of of action?

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 19 Apr 2001, Scott Cressler wrote:

> I'm trying to decide how to structure our app.  We want to use templates to
> separate the layout from the content, and we want to use the Struts
> framework to separate the business logic from the presentation.  I've been
> converting several parts of our site and am happy with the results.
> However, we also want to, as much as possible, separate out reusable parts
> of the presentation into separate JSP pages (sort of "components").  For
> example, we have a header and have it separated into header.jsp.  This JSP
> page can take parameters and can also adjust itself based on its
> "environment", that is, what it finds in the request.  But to do so, it has
> a bunch of Java in the JSP (it was also developed before I came and without
> an eye to keeping the business logic separate).
> 
> What I'd like to do is change the header.jsp to pull the Java out.  I see
> several possible ways to do that.  One is to essentially develop an Action
> that sets up for the JSP and then forwards to the JSP.  So, for example,
> that would change the code in my current pages like:
> 
> <jsp:include page="/components/header.jsp" flush="true"><jsp:param
> name="atab" value="main"/></jsp:include>
> 
> to look like:
> 
> <jsp:include page="/components/header.do" flush="true"><jsp:param
> name="atab" value="main"/></jsp:include>
> 
> but I'm not sure what the performance implications of this would be.  That
> is, what is the difference between a <jsp:include> of a JSP page versus an
> Action.  In the case of the Action, it would be routed through the app
> server (resin in our case...for now), through the ActionServlet and Action,
> and then forwarded to the JSP.  (Now that I think of it, I'm not sure this
> would even work, but I think it should.)  In the JSP case, is it also routed
> through the app server, so the only difference is where the business logic
> is done?
> 

This would work, as long as the action called for "/header.do" did a
forward to "/header.jsp" when it was done.  The performance impact is the
cost of one extra RequestDispatcher.forward() call, which is not very
heavy -- it all happens on the server side.

Another alternative to explore is using the include directive (<%@ include
file="xxx.jsp" %>) instead.  This works like the "#include" directive in a
C program, and causes the included text to be processed at page compile
time, just as if it were part of the containing page.  I'm not sure how
practical this would be for dynamic headers, though.

> Another idea I have is to create one or more custom tags that will set up
> for the header JSP.  That way, the JSP could be included just as header.jsp,
> but the Java and business logic would have been extracted to the custom
> tag(s).  The negative of this is it is a departure from the Struts
> architecture and puts the business logic in a sort of unexpected place.
> 

Is it really business logic, or is it presentation logic?  Sometimes the
line gets a little fuzzy ...

> The last idea I had was to somehow cause the Action for the enclosing page
> (that is, the page that does the <jsp:include> of the header) to do the
> logic and setup necessary for the header.  Then the header would just get
> what it needs from the request and could remain a JSP, not an Action.  The
> negative of this is that the logic for the header would be performed by the
> Actions of all the pages, although it could be included in the BaseAction
> that I extend for my Actions.
> 
> BTW, we have one motivation that others may not have: we are developing an
> example application that will be given to our customers to base their app
> on.  So we want to structure things in the best, most understandable way.
> 
> Thanks for any help,
> Scott
> 

It might also be worth looking at the template tags included with Struts,
or one of the related alternative template approaches.

Craig