RE: Should IncludeTag be used instead of <%@ include...> or how navigation menu should be build

[Colin Sampaleanu <co...@Bspark.com>]

> -----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...

Re: Should IncludeTag be used instead of <%@ include...> or how navigation menu should be build

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Colin Sampaleanu wrote:

>
> _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...

Yep, that is *definitely* worth fixing.  And it turns out to be easy as well.
RequestDispatcher.include() doesn't change the path elements of the request
object, but it *does* store request attributes for the path elements of an
"include", so the controller servlet can easily tell whether this is the case
or not.  I will fix that in the 1.0 code base shortly.

Craig