Red Hat Web Application Framework 6.1 Manuel D’Utilisation

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.

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 run on each request, even if the components used are static. This is because the

show:...

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.

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 { %