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 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? :-) 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: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: push v. pull (was[xsl] Never us, Graham Seaman | Thread | Re: push v. pull (was[xsl] Never us, Graham Seaman |
Re: push v. pull (was[xsl] Never us, Graham Seaman | Date | Re: [xsl] Testing if something is n, Jeni Tennison |
Month |