struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <co...@Bspark.com>
Subject RE: Should IncludeTag be used instead of <%@ include...> or how navigation menu should be build
Date Fri, 03 Nov 2000 20:51:00 GMT
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: November 3, 2000 2:11 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Should IncludeTag be used instead of <%@ 
> include...> or how
> navigation menu should be build
> 
> Robert Leland write:
> 
> > > The <struts:include/> tag (like <jsp:include/>) performs 
> a *runtime* include
> > > action.  It works best when the included component is 
> itself dynamic, and/or
> > > you want to be able to modify it independently.
> > >
> > > The <%@ include %> directive performs a *compile time* 
> include, just like
> > > the #include directive in C or C++.  This textually 
> embeds the text of the
> > > included page into the containing page, just as if you 
> combined everything
> > > with a text editor.  Therefore, the included content has 
> access to the
> > > declared beans in the including page.
> > >
> > > If you want to make beans in the calling page available 
> to the included
> > > page, make sure you use REQUEST scope rather than PAGE scope.
> > >
> >
> >  By dynamic do you mean jsp servlets ?
> >
> >   Here is where I am confused: According to the book
> >   "Core Servlets and JavaServer Pages". Marty Hall
> >  " Use the include directive if included files will use JSP 
> constructs.
> >    Otherwise use jsp:include."
> >
> >   For files included via jsp:include cannot -contain- JSP.
> >
> >   Is this a correct interpratation of the JSP spec ?
> >
> >   This seems to just the opposite from what you were saying !?!
> >
> 
> You can indeed call a JSP page or a servlet using 
> <jsp:include> if you want to.
> This can be quite useful when assembling a single page from 
> multiple dynamic input
> sources (for example, using the templating tags that will be 
> in Struts 1.0).
> Effectively, the included page is "called" by the servlet 
> container for you, and
> it's output inserted into the page that is now being 
> generated at runtime (rather
> than at compile time).
> 
> The issue in this particular case is that the JSP you include 
> is a completely
> independent "page" (in the JSP scope sense), so it does not 
> have access to any
> page-scope information (or defined variables) from the 
> calling page.  However,
> request scope can be used to share information between the 
> calling page and the
> called page that is loaded by <jsp:include>.  In fact, this 
> is precisely the
> difference between page scope and request scope.
> 
> The underlying mechanism that is being used is that of 
> RequestDispatcher.include()
> in the servlet specification, which is what the code 
> generated by <jsp:include>
> actually ends up using.

_but_ with the present implementation of ActionServlet you can not use
jsp:include include a url that is a struts Action request/call. This is
because RequestDispatcher.include() does not change the path element and
parameters of the request object, and ActionServlet depends on these to
decide which action to call. ActionServlet will still think the request is
for the original resource (the one doing the include). What I have used
successfully is to have a modified subclass of ActionServlet that can
recognize a special 'path override' parameter that it can use instead to
decide on the action to take. I would suggest that this functionality is
worth putting in the base ActionServlet implementation...

Mime
View raw message