Chapter 5. WAF Component: Presentation 29
1. The requested JSP obtains an XML document from a Bebop page object and the current request
state.
2. The tags in the requested JSP construct a new XML document, copying pieces from the Bebop
page where needed.
3. The resulting XML is passed as the XML input to an XSLT transformation step, using global
stylesheets.
4. The final result is sent to the user’s browser.
5.4.3. Relationship Between Static and Dynamic Pages
The JSP tag libraries for Bebop are designed to work together with Bebop’s model of static, shared
Page and Component objects, while providing familiar semantics to JSP authors. The division in
Bebop between static Page objects that produce dynamic output on each request is reflected by the
division of tags into two separate libraries:
A library of define:... tags.
Used for creating Bebop components.
The define:... tag library defines a Bebop page and its components with JSP tags. Since
the page structure may be static, JSP code in the define:... tag library is not guaranteed to
run on each request. Care must be taken to not put any runtime expressions or scriptlets into a
define:page block that are expected to run on each request.
A library of show:... tags.
Used for displaying the output form Bebop components inside a JSP page.
The show:....tag library is dynamic. Any Java code inside a show:page block is guaran-
teed to runon each request,even ifthe components used are static.This is because theshow:...
tags manipulate the XML output produced by Bebop components on each request, and not the
components themselves. Any valid JSP runtime expressions, tags, or scriptlets may be used in
conjunction with show:... tags and they should yield the same results they would in any other
JSP.
Caching in
define:page can be suppressed with the JSP tag attribute cache="no". This will
cause the JSP define:page tag, along with the code and all the other tags inside it, to execute on
each request; the entire Page object will be re-created and garbage-collected on each request.
Warning
Although it seems there could be some benefit to changing the structure of a Page on each request,
it is not recommended.
Variations on the structure of a page will interfere with Bebop’s state maintenance, because the
URL and form variables that preserve state for individual components are linked to the component’s
position in the overall page structure. Runtime errors or unpredictable results may occur if a page’s
structure differs between subsequent requests.
Certain types of non-structural page variations between requests are permissible. Most importantly,
the individual options in option groups (radio groups, select widgets, checkbox groups) are not com-
ponents themselves, so the following code is permissible:
define:radioGroup
% loop { %
