This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: making html output for application pages


on 4/22/02 10:02 AM, Hunsberger, Peter at Peter.Hunsberger@stjude.org wrote:

>> I'm currently in the process of converting some legacy .jsp files to
> output
>> xml which will then be processed by xslt to output the pages.
> 
> <snip>...</snip>
> 
>> When generating the pages, the xsl figures out the general layout of the
>> page and values of things like the page title, headers. This requires lots
>> of instances of:
> 
>> <xsl:choose>
> 
> <snip>...</snip>
> 
>> This means that when someone is translating the "index" page, they need to
>> go through the entire document and find each of these choices and work on
>> the little bits of text inside.
>> 
>> I had thought it might be easier if I had some kind way of declaring all
> the
>> bits of text as variables at the top of the page, but I ran into a
> variable
>> scoping problem.
>> 
> Bernie,
> 
> In addition to using modal templates you may want to look at using imported
> or included templates.
...
> This allows the main template for each page to contain all the page specific
> logic.  In the generic templates I usually have things like table builders
> or dialogue builders.  All the page specific setup is completed by the time
> the generic templates are called.  However, the page specific templates
> typically don't run more than about 80 lines of code at most, and they don't
> do all the specific formatting; they pass generally named variables that
> contain page specific information.
> 
> As to choosing between import and include; import is generally more flexible
> and allows you the equivalent of multiple inheritance.  However, there can
> apparently be some issues with passing global parameters around with
> imported templates.  I've never run into them, but if you really need to
> pass a lot of variables around include might work better for you...
> 

This is an interesting proposal.

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.

This is certainly possible since I am controlling both sides of the
transformation and can tell the jsp side which top-level template to use.

You mention the problem of scoping in the xsl context that I'll need to be
wary of.

My initial thought on this would be to have a the top-level template be
something like this, but I'm not sure it will work when it comes to the
scoping issue.

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

given the xml data produced:
<top>
  <page>index</page>
  <mydata>
    <row>
      <col1>First column</col1>
      <col2>Second column</col2>
      <col3>Third column</col3>
    </row>
  </mydata>
</top>


and the top-level template contains something like this for the "index" page
"index.xsl".:
<xsl:variable name='pageHeader'>This is the index page</xsl:variable>

<xsl:template name='pageBody'>
  <table>
    <tr>
      <td>Some data</td>
      <td>In a table</td>
      <td>that is only on the index page</td>
    </tr>
    <xsl:for-each select='mydata/row'>
      <tr>
        <td><xsl:value-of select='col1' /></td>
        <td><xsl:value-of select='col2' /></td>
        <td><xsl:value-of select='col3' /></td>
      </tr>
    </xsl:for-each>
  </table>
</xsl:template>

<xsl:import href="genericPage.xsl" />


and genericPage.xsl, includes the following:

<xsl:template match="top">
    ...
    <xsl:if test='$pageHeader'>
       <font xsl:use-attribute-sets="headerFont">
         <xsl:value-of select='$pageHeader' />
       </font>
       <br /><br />
    </xsl:if>
    ...
    <xsl:call-template name='pageBody' />
</xsl:template>

--------

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

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

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

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


> I should also note, that I use modal templates in addition to the imported
> and included templates.  In our case they distinguish between handling data
> from different sources that has similar structure, but different output
> requirements.  However, once again the pattern is that of a global switch.
> 

I have already begun making some changes to use the modal template idea as
suggested by J.Pietschmann in his response. This is a huge learning
experience and the list has been extremely helpful.

This was my first post, but I've been experimenting and reading profusely
over the past few weeks while climbing this learning curve. I realize I'm
not quite thinking in xsl yet, but I appreciate the guidance and hope I can
make the necessary paradigm shift.



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]