Re: RE: syntax sugar for call-template
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format