RE: [xsl] making html output for application pages

Subject: RE: [xsl] making html output for application pages
From: "Hunsberger, Peter" <Peter.Hunsberger@xxxxxxxxxx>
Date: Mon, 22 Apr 2002 15:52:00 -0500
> I guess what it means is that I'd create a parallel page for each .jsp
page
> (or set of similarly functioning jsp pages) that would be simply the
> definitions for the look of that page.

We create parallel pages for each page that needs formatting above and
beyond what the generic/main template can provide.  In practice this has
meant every page, but that's more due to lack of consistent design across
pages then anything else, the design of our system is such that some pages
could in theory invoke the main template directly and use the resulting
default behaviors to get perfectly acceptable output.

> Let's say we're talking about a page header that appears on some pages,
but
> not necessarily others.

<snip>...</snip>

> Will the code in genericPage.xsl have access to "$pageHeader" or will the
> context have been switched at that point?

The context will be fine, what you're referring to is variable and parameter
scope issues. You will have to test for how this is handled using your
specific XSLT implementation.  I believe the issues is of lack of formal
definition in the standard and resulting divergent implementations (anyone
?)

> Will genericPage.xsl be able to call the pageBody template that is defined
> in index.xsl?

I believe so.

> Will index.xsl have access to the "top" data as the current node when the
> matching template is in genericPage.xsl?

The input tree remains the same input tree across all templates regardless
of include or import. Normal context rules apply as though import or include
was not used.

You may want to start looking at template priorities.  It would be possible
to define the same template twice (or more times) in say both the top level
template and an imported template.  Import gives you a specific mechanism
for invoking imported templates, include doesn't; everything is at the same
level.  Given overlapping template match patterns you need to make sure the
priorities are set properly to pick the one you want.  Generally, you're
going to want to set the top level template priorities higher and the more
generic (default action) template priorities lower.

> If there are context problems in this case, can I assume that using
> "include" instead of "import" will solve them?

Again, you'll have to test this to be sure.  It won't be context issues but
rather variable or parameter scope issues.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread