Re: push v. pull (was[xsl] Never use for-each)

Subject: Re: push v. pull (was[xsl] Never use for-each)
From: Graham Seaman <graham@xxxxxxxxx>
Date: Tue, 6 Nov 2001 14:37:19 +0000 (GMT)
On Wed, 31 Oct 2001, Thomas B. Passin wrote:

> One reason the html might get entangled is that the html was not really
> designed but just grown.  In many cases it's better to design the document
> into semi-independent parts that get generated by different templates.  You
> could call this a "document architecture".  For example, if you want to
> create a page with four quadrants, using a table structure, you could do
> something like this:

Great! In fact I find I've been moving to something like this - but I
hadn't made it half so explicit to myself. Don't things always look
obvious when someone else says them? :-) 

It's still a language which tangles up code and output much more than
some, whatever you do (as far as I can see). I'm used to a perl templating
system where the code in the template largely just supplies variable
values (though there may be a lot of database fetching off the template).
So if say a <td> contains a number supplied from the db, the designer can
choose whether to show it as a number, or a coloured block of a certain
height, etc. (which would need adjustment of other table elements) without
seeing much perl at all - certainly not the database calls (equivalent
to not needing to see xpath expressions in this case, I guess).

Might a way to get a similar separation of xsl and html
be to chain the output through several stages of xsl (ie. with the
data extraction from xml being in the first stages, and the later
stages being more presentation oriented). Is this common practice?
Hard to do?

> whose content is supplied by xslt templates.  In fact, the xml for each
> block could come from different files, brought in by document(), and the
> stylesheets for each major block could be imported.
> 
> With this approach, you can end up with a main driver file that coordinates
> and customizes the parts.  The building blocks give you a chance to avoid
> the spaghetti.  You have to have some html bits in the xslt templates, but
> they don't have to become spaghetti, never to be separated again.
> 
> Here's a fragment from a real working stylesheet of mine:
> 
> <h3><xsl:value-of select='title'/></h3>
>  <xsl:apply-templates select='header'/>
>  <form action='landaction.html' method='post'>
>        <xsl:apply-templates select='file'/>
>        <xsl:apply-templates select='section'/>
>        <input type='submit' value='Send Questionnaire Data'/>
>  </form>
> 
> The "file" template create a hidden field with a data value, and the
> "section" template handles a series of recursive (nested) sections.  Of
> course, the template for "section" is more complicated than this, but this
> part is the driver for an extremely complex form.  You can easily see the
> structure of the html, and I wouldn't call it "entangled".
> 
Nice. Do you have a way to handle the returned cgi parameters in xsl,
or are you doing that in another language? I'm giving my cgi parameters
names which are xpath expressions, so I can generate an xml file from
them when they're returned and then run xsl on that - it works, but 
feels a bit clunky. 

> Cheers,
> 
> Tom P
> 
Thanks for the advice,
Graham



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


Current Thread