Subject: Re: [xsl] nested templates? From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Thu, 17 May 2001 08:39:26 +0100 |
Hi Alex, > instead, I need to be able to take a prototype: [snip] > and _rapidly_ construct a stylesheet from that prototype, which > means I need to retain its correct, original structure. [snip] > But I prefer the idea of defining named subtemplates within a scope, > so I can replace them at will with "included" templates. Of course > that's only useful if you're constructing complex documents, but > that's exactly what I'm doing. The way Chris (Bayes) has been talking implies that the 'nested templates' would be locally scoped and be applied in preference to 'global templates'... oh and he's talking about matching templates rather than named ones :) Of course we're talking about made-up syntax here, but I'm not sure how this would tie in with what you say about *replacing them* with 'included' templates. How would you include them? A local xsl:include? (This seems to me not unlike the stuff that Alexey Gokhberg was talking about a while ago - locally scoped functions, lambdas, all that stuff.) Anyway, I don't think it would be too hard to write a stylesheet that takes a stylesheet that uses nested templates and transforms it into XSLT 1.0 by flattening it, adding modes to matching templates and namespaces to named templates so that you get the effect you're after. You should use a different (extension) namespace for the nested templates (and any other non-XSLT syntax that you introduce). This is the general approach that Oliver Becker used for a looping construct. You can submit it to the EXSLT site as an extension element if you don't want to think up the namespace yourself. > So, the idea is to build a default 'form layout' which takes care of > table structure, conditionally printing errors, etc - and a set of > little includes which take care of the actual html form element > construction: (Your terminology of 'little includes' is a bit confusing for those of us that are used to using 'include' to mean including a stylesheet using xsl:include. It looks like you mean 'little templates'?) > <xsl:template name="text"> > <input> > <xsl:attribute name="type"><xsl:value-of > select="input/type"/></xsl:attribute> > <xsl:attribute name="size"><xsl:value-of > select="input/size"/></xsl:attribute> > <xsl:attribute name="maxlength"><xsl:value-of > select="input/maxlength"/></xsl:attribute> > <xsl:attribute name="value"><xsl:value-of > select="input/value"/></xsl:attribute> > </input> > </xsl:template> (You could simplify this to: <xsl:template name="text"> <input type="{input/type}" size="{input/size}" maxlength="{input/maxlength}" value="{input/value}" /> </xsl:template> Attribute value templates are you friends.) > It isn't realistic to store all of those templates inside every form > file, and it's dumb (for reasons you probably beat me to) - so > instead of doing that, I will include them dynamically (if I can get > <xsl:call-template name="$variable_name"> to work correctly) based > on the <input> definition above. This is where I start thinking I don't understand at all, probably because of terminology again :) Why are you storing templates in a form file? Isn't that the *source*? Shouldn't you be storing templates in a stylesheet? You can't dynamically include stylesheets. If you want to make sure that a stylesheet only contains the templates that it needs to perform a particular transformation, then you need a two-pass solution: the first to create a stylesheet that holds only the relevant templates (perhaps by including them with xsl:include), and the second to use this stylesheet to transform the source. (My instinct is that this two-pass approach is likely to be less efficient than a one-pass approach overall, unless you're going to reuse the result of the first pass multiple times. I get the impression that you're worried that having the processor search through lots and lots of templates to find the one matching a particular node is a problem, that you're worried that the more templates you have, the more inefficient the code is going to be because the processor will be spending lots of time finding them? I honestly don't think that's a performance problem you should be worried about - in all his lists on increasing the efficiency of stylesheets, Mike Kay has never said 'use fewer templates'.) You will never 'get <xsl:call-template name="$variable_name"> to work correctly' because it isn't possible to dynamically work out the name of the template that you intend to call. The only thing you can do is: <xsl:choose> <xsl:when test="$variable_name = 'foo'"> <xsl:call-template name="foo" /> </xsl:when> <xsl:when test="$variable_name = 'bar'"> <xsl:call-template name="bar" /> </xsl:when> ... </xsl:choose> Or use the two-pass solution described above to dynamically create the stylesheet that includes the template that makes the call :) Ahh... it occurs to me that perhaps the reason you want to do this is because you need different templates for the different kinds of form elements, but are struggling to see how to do that when using named templates? It would be a lot easier for you if you used matching templates rather than named ones. Then you could have different templates for different types of input: <xsl:template match="input[type = 'text']"> <input type="{type}" size="{size}" maxlength="{maxlength}" value="{value}" /> </xsl:template> <xsl:template match="input[type = 'dependent_pulldown']"> ... </xsl:template> Dunno if that helps or not, but there you go. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] nested templates?, Alex Black | Thread | Two pass XSLT, was [xsl] nested te, Kurt Cagle |
Re: [xsl] Xalan Java TransformerExc, Sudhir Malhotra | Date | [xsl] [xsl] £ character reference, Tanzila Mohammad |
Month |