Points to remember about include directive and include action
You can build a page with reusable components
using one of two include mechanisms—the
include directive or the <jsp:include> standard
action.
The include directive does the include at transla-
tion time, only once. So the include directive
is considered the appropriate mechanism for
including content that isn’t likely to change after
deployment.
The include directive essentially copies everything
from within the included file and pastes it into the
page with the include. The Container combines all
the included files and compiles just one file for the
generated servlet. At runtime, the page with the
include runs exactly as though you had typed all
the source into one file yourself.
The <jsp:include> standard action includes the
response of the included page into the original
page at runtime. So the include standard action
is considered appropriate for including content
that may be updated after deployment, while the
include directive is not.
Either mechanism can include dynamic elements
(JSP code with EL expressions, for example) as
well as static HTML pages.
The include directive is the only position-sensitive
directive; the included content is inserted into the
page at the exact location of the directive.
The attributes for the include directive and
the include standard action are inconsistently
named—the directive uses “file” as the attribute
while the standard action uses a “page” attribute.
In your reusable components, be sure to strip
out the opening and closing tags. Otherwise, the
generated output will have nested opening and
closing tags, which not all browsers can handle.
Design and construct your reusable pieces know-
ing that they’ll be included/inserted into something
else
You can customize an included file by setting (or
replacing) a request parameter using the
<jsp:param > standard action inside the body of a
<jsp:include>.
We didn’t show it in this chapter, but the
<jsp:param> can be used inside the body of a
<jsp:forward> tag as well.
The ONLY places where a <jsp:param> makes
sense are within a <jsp:include> or a
<jsp:forward> standard action.
If the param name used in <jsp:param> already
has a value as a request parameter, the new
value will overwrite the previous one. Otherwise, a
new request parameter is added to the request.
The included resource has some limitations: it
cannot change the response status code or set
headers.
The <jsp:forward> standard action forwards the
request (just like using a RequestDispatcher) to
another resource from the same web app.
When a forward happens, the response buffer is
cleared first! The resource to which the request
was forwarded gets to start with a clean output.
So anything written to the response before the
forward will be thrown away.
If you commit the response before the forward
(by calling out.flush(), for example), the client will
be sent whatever was flushed, but that’s it. The
forward won’t happen, and the rest of the original
page won’t be processed.
using one of two include mechanisms—the
include directive or the <jsp:include> standard
action.
The include directive does the include at transla-
tion time, only once. So the include directive
is considered the appropriate mechanism for
including content that isn’t likely to change after
deployment.
The include directive essentially copies everything
from within the included file and pastes it into the
page with the include. The Container combines all
the included files and compiles just one file for the
generated servlet. At runtime, the page with the
include runs exactly as though you had typed all
the source into one file yourself.
The <jsp:include> standard action includes the
response of the included page into the original
page at runtime. So the include standard action
is considered appropriate for including content
that may be updated after deployment, while the
include directive is not.
Either mechanism can include dynamic elements
(JSP code with EL expressions, for example) as
well as static HTML pages.
The include directive is the only position-sensitive
directive; the included content is inserted into the
page at the exact location of the directive.
The attributes for the include directive and
the include standard action are inconsistently
named—the directive uses “file” as the attribute
while the standard action uses a “page” attribute.
In your reusable components, be sure to strip
out the opening and closing tags. Otherwise, the
generated output will have nested opening and
closing tags, which not all browsers can handle.
Design and construct your reusable pieces know-
ing that they’ll be included/inserted into something
else
You can customize an included file by setting (or
replacing) a request parameter using the
<jsp:param > standard action inside the body of a
<jsp:include>.
We didn’t show it in this chapter, but the
<jsp:param> can be used inside the body of a
<jsp:forward> tag as well.
The ONLY places where a <jsp:param> makes
sense are within a <jsp:include> or a
<jsp:forward> standard action.
If the param name used in <jsp:param> already
has a value as a request parameter, the new
value will overwrite the previous one. Otherwise, a
new request parameter is added to the request.
The included resource has some limitations: it
cannot change the response status code or set
headers.
The <jsp:forward> standard action forwards the
request (just like using a RequestDispatcher) to
another resource from the same web app.
When a forward happens, the response buffer is
cleared first! The resource to which the request
was forwarded gets to start with a clean output.
So anything written to the response before the
forward will be thrown away.
If you commit the response before the forward
(by calling out.flush(), for example), the client will
be sent whatever was flushed, but that’s it. The
forward won’t happen, and the rest of the original
page won’t be processed.