Subject: RE: [xsl] nested templates? From: "Chris Bayes" <Chris@xxxxxxxxxxx> Date: Thu, 17 May 2001 00:03:07 +0100 |
Kurt, I wasn't suggesting that it should be. I was just comparing. Like Rick just wrote me we have flogged this dead horse I agree. I was just kicking around some ideas. How is the svg going? Any good examples I can link to? (credits o'c') This thing is blooming ;-)) Ciao Chris XML/XSL Portal http://www.bayes.co.uk/xml >-----Original Message----- >From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx >[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Kurt Cagle >Sent: 16 May 2001 21:33 >To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx >Subject: Re: [xsl] nested templates? > > >Alex, > >I don't think that XSLT should be OO, but I argue in a book that >I'm writing >that XSLT, in conjunction with Schema, XLink and RDF, works best when the >whole is considered as an OO system. XSLT serves as a mechanism >for defining >methods on XML objects defined by schemas, schemas can be used as >constructors, inheritance is a natural consequence of the importing and >including mechanisms that XSLT has, and the stateless nature of XSLT >transformations makes concepts such as garbage collection pretty much moot. >The definition of encapsulation has to be stretched a bit, since you have >the multiple distinct conditions that XSLT makes it possible to create >methods that apply equally well to schemas that may have no particular >elements in common, but that are relationally similar. > >-- Kurt > > >----- Original Message ----- >From: "Alex Black" <enigma@xxxxxxxxxxxxxxxx> >To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> >Sent: Wednesday, May 16, 2001 4:54 PM >Subject: Re: [xsl] nested templates? > > >> >> hi tom, >> >> thanks - xsl:call-template is essentially what I was looking for re: >> "element handlers" >> >> I must disagree strongly with the idea that XSLT should be OO, it is >> specifically for building complex, nested _hierarchies_ - thus my post. >> >> Some examples from other posts: (as I have apparently started a fire) >> >> >> > Why not? A template matches a node, matching it by node type, >by element >or >> > attribute type name, or by some other identifier such as an ID or key >> > value. It doesn't matter where in the source tree the node is, or how >deep; >> > once that node is picked up for processing (through an >xsl:apply-templates >> > instruction), the template applies. For a given type of node, you get a >> >> That's fine if you're dealing only with arbitrary nodes, which in _some_ >> cases is exactly what I want to be able to do. xsl:call-template is >perfect >> for those cases, as far as I'm concerned. >> >> however, in many other cases I need to have a complete, editable picture >of >> the hierarchy of a document I'm creating. >> >> the lots-of-little-bits-way doesn't give me that. I've used nearly every >> kind of template system on earth, and I have found that I work >much faster >> if I can mix "objects" (i.e. xsl:call-template for a "bookmark" in the >> example I gave) and "documents" (large nested hierarchies, consisting >mostly >> of layout code) >> >> > given output. Why is this not useful? It seems particularly elegant and >> > powerful especially for the sort of semi-structured, >> > not-entirely-predictable, arbitrarily deep, hierarchical data sets >> > (documents) that are so common among markup applications. Many >of us use >it >> > every day. >> >> Above, I have nothing against templates that do that, but I see no reason >to >> _prevent_ users from nesting templates. >> >> I'm not suggesting that you should _have_ to nest your templates, I think >it >> should be something that XSLT can do. >> >> >> > Since you used the magic word "goto", I think that the lack of >structure >is >> > what is conceptually wrong with the original idea of "nested >templates(from >> > Alex Black) in the first place. This is like the (legal) COBOL >structure >> >> This is confusing, as I am implying that I would like a more >deeply nested >> structure that is currently doable with xslt. >> >> I want _more_ structure, not _less_ structure. >> >> > of PERFORM paragraphs A THRU K, and then having other places where you >just >> > PERFORM B (which was in the original sequence A THRU K). This leads to >> > unmaintainable spagetti code in a big hurry. I think this is why >Wendell >> > Piez and Tom Passin were urging the "lots of little bits" approach. In >> > fact, Wendell was quite explicit about this (though he may not >appreciate >> > my "help" here). >> >> Right, which is why you should be able to do both, and mix them >as you see >> fit. >> >> But I really can't come up with a good reason why it should be _illegal_ >> syntax to nest <xsl:template> elements. >> >> >> _alex >> >> >> -- >> alex black, ceo >> enigma@xxxxxxxxxxxxxxxx >> >> the turing studio, inc. >> http://www.turingstudio.com >> >> vox+510.666.0074 >> fax+510.666.0093 >> >> >> >> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list >> > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] nested templates?, Alex Black | Thread | Re: [xsl] nested templates?, Uche Ogbuji |
Re: [xsl] nested templates?, Alex Black | Date | RE: [xsl] nested templates?, Chris Bayes |
Month |