Re: [xsl] RE: syntax sugar for call-template

Subject: Re: [xsl] RE: syntax sugar for call-template
From: "Clark C. Evans" <cce@xxxxxxxxxxxxxx>
Date: Thu, 15 Feb 2001 13:04:29 -0500 (EST)
On Thu, 15 Feb 2001, Dimitre Novatchev wrote:
> >  In the past I've considered doing this in Saxon. But I'm undecided whether
> >  the attribute value should be an AVT (therefore always yielding a string) or
> >  an XPath expression (in which case any value can be passed, but strings need
> >  to be written in double-nested quotes, e.g. arg="'London'"). Any views?
> >  
> 
> Obviously, only the latter will make it possible to substitute any 
> xsl:call-template with xf:func.

As pointed out by Steve Muench, the attribute version will 
not be able to pass result fragments.  However, a slightly
modified version using "elements" will do the trick...

  <xf:func one="xpath" />           <xsl:call-template name="func">
                          becomes     <xsl:with-param name="one" 
                                                      select="xpath" />
                                    </xsl:call-template> 


  <xf:func one="xpath" >            <xsl:call-template name="func">
    <two>                             <xsl:with-param name="one"
      <res>frag</res>     becomes                     select="xpath" />
    </two>                            <xsl:with-param name="two">
  </xf:func>                             <res>frag</res>
                                      </xsl:with-param>
                                    </xsl:call-template>

Clearly, the attribute-only version is much cleaner.  However,
the element syntax below could be used for those times when a 
result fragment must be passed... I'm not sure I like it though.

> >  (Though actually, I've also held off because I'm reluctant to implement
> >  non-portable extensions if they provide nothing more than a saving in
> >  keystrokes ...)
> 
> They provide far more than saving in keystrokes... Consider the
> improved readability, understandability and therefore reliability 
> of the code. Consider also the cost savings in code
> maintenance. And the ability to enter more code in less time... :o)))
> 
> Some mathematicians argue, that whole new disciplines appeared or 
> were significantly influenced by the appearance of new, better
> notation. xsl:call-template is clearly far from the optimal notation
> possible.

Neat.  The choice as to what is in-lined and what is made into
a seperate template is largely based (in my case) upon the
difficulty required to setup a seperate template and call
the template.  In my experience, when this pain can be 
lessened... then better modulization will be the result.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread