Subject: Re: [xsl] RE: syntax sugar for call-template From: "Clark C. Evans" <cce@xxxxxxxxxxxxxx> Date: Sat, 17 Feb 2001 12:39:00 -0500 (EST) |
On Fri, 16 Feb 2001, David Carlisle wrote: > because if you introduce a system for binding XSLT written code to Xpath > functions that _only_ does simple cases eg, not cope with qnames as > function names or node sets as argumnements, then you may find your > options are severly limited when you come to specify the "full job" > if you have to keep compatible with a half way solution that has been > added earlier. David, thank you for your reply. I'm proposing this beacuse I have some 30+ stylesheets in the work that I'm doing. And they are quickly becoming un-manageable. More importantly, I'm duplicating "template fragments" that are very common since the overhead for splitting this into a callable template is so brutal. This leads to bad modulization. I need (ok, have implemented) a simple mechanism which is *syntax sugar* for calling templates that can be used with existing XSLT via a meta-stylesheet. Thank you for pointing out the "qname" limitation. This is interesting, beacuse I've never used qnames as template names. And, I don't see very many examples out there that do. So... I see this as an esoteric case. I consider myself a heavy XSLT user and I don't need them. Now. XSLT may need a nice "packaging" mechanism. However, I hardly feel that qnames will make my life any easier. For now, for those concerned with name collisions, just use a "dnsname" like "func.clarkevans.com" The chance of a name collision here is, well, infinitesmal. Your other limitation, is that you can't call the code through XPath. This is not a problem that I need to be solved. Most of my XPath expressions are rather simple already, calling templates from XPath is also esoteric. Even so, I can call the template, return the results, stuff the result fragment into a variable and call an extension function to-nodeset to make the information available via XPath. This isn't simple, but it is very understandable... Your final limitation is that I can't pass node-sets as arguments. My current solution does not have this problem: <xf:func one="xpath" /> <xsl:call-template name="func"> becomes <xsl:with-param name="one" select="xpath" /> </xsl:call-template> In short, I hardly see why this simple solution is "severly limiting". It may not cover every case in which people may want to do such a thing... but this isn't the goal. The goal is to help template modulization with *existing and future* XSLT processors. Nothing more, nothing less. Clark XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] RE: syntax sugar for call, David Carlisle | Thread | Re: [xsl] RE: syntax sugar for call, David Carlisle |
Re: [xsl] Rescuing XSLT from Niche , Michael Beddow | Date | Re: [xsl] RE: syntax sugar for call, Clark C. Evans |
Month |