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

Subject: Re: push v. pull (was[xsl] Never use for-each)
From: "cutlass" <cutlass@xxxxxxxxxxx>
Date: Tue, 6 Nov 2001 14:50:58 -0000
From: "Graham Seaman" <graham@xxxxxxxxx>
> 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
> > into semi-independent parts that get generated by different templates.
> > 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? :-)

in a real world application, u will find that it exhibits all forms of
development ( waterfall vs blah blah ), i.e. organic or designed; document
or database. the intermingling at different phases and scope is what really
causes any complexity here; but a good application ( now... ) should be
flexible enough.

> 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

hehe, u must be joking, perl to me is the end all be all mangler of readable
code ! though the verboseness of xslt tends to get real boring after awhile.

the very nice thing is that xslt is highly modular, which can be good for
code maintenance ( and organic code growth ) but very poor for code
performance; as once one strings everything together...u find out that
things take a bit longer then is acceptable.

> 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?

multiple stage transformation is a basic cornerstone and is common practice.
not hard to do.

as for a simplest web type framework i would suggest

global.xml: global elements, data urls,and possibly session data of client
global.xsl: holds global vars, common location paths, common xpath, global
language templates ( ie selector based on @xml:lang attribute, etc ), data
handling templates ( possibly call-templates )

asset.xml: raw xml for data to be used in application
asset.xsl: styling aspects ( images, text, etc )

have all other data as external and use a global call-template to access
external data from within your local template.

inherit these 4 templates in every template for the web app, though with
larger apps u will definately have to get more sophisticated.

> > 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.
> >
> 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.

uhhh, not quite sure what u mean, but if u want to pass the cgi params into
the xslt for use, u can use xsl:param to do this ( with varying techniques
of pumping them in based upon your parser of choice ).

there is no native extension that will reveal or parse native cgi params
though one can bind a function to do this as an external function.

cheers, jim fuller

 XSL-List info and archive:

Current Thread