Subject: Re: XT extension mechanism From: James Clark <jjc@xxxxxxxxxx> Date: Mon, 04 Jan 1999 09:11:00 +0700 |
Flow Simulation wrote: > > James Clark wrote: > > > XT's new experimental extensibility mechanism is based on the idea of > > filtering fragments of the result tree through an object. > > The xsl:filter element specifies a filter. It has attributes that > > specify the filtering object in the same way as the HTML 4.0 OBJECT tag. > > which is great if you're building on top of Java or COM, but not so clear > to me how you would use it if you weren't using either of those technologies. Just as with the HTML 4.0 OBJECT tag, there is no restriction to Java and COM. The attributes can point to a resource containing script. <xsl:filter classid="http://www.jclark.com/scripts/total.js" codetype="text/javascript"> ... </xsl:filter> > > I'm also thinking about supporting script directly, using something like > > this: > .. > > > <xsl:template match="foo"> > > <xsl:filter type="text/javascript" script="diddle(this)"> > > <xsl:apply-templates/> > > </xsl:filter> > > </xsl:template> > > That looks great. But I'm not sure how this improves on the <eval> element > in e.g. the Microsoft XML Tutorial 15. In the latter case you can drop scripted > elements into the template whereas with <filter> you need to programmatically > do this, I think. Huh? In one case the script is in an attribute value, in another it's in content. The major difference is that xsl:filter acts on the result tree, not the source tree. A mechanism that acts purely on the source tree can never be adequate. Consider the case where you want to use a different style for every other row of the table. You can do this with eval as in the old submission, the differences in the row-handling are non-structural (eg a different value for an attribute). But consider a variation on this case: the rows are generated from source data which is sorted using xsl:sort. With xsl:eval you're out of luck, but with xsl:filter you can do it. Another major difference is that with xsl:eval (at least as it was in the submission) you can only generate strings. With xsl:filter you can use the DOM to modify the element structure of the result: for example, you could transpose rows and columns. > Is it easier to implement, or a question of language "purity"? > > If you use script (either way), I wonder if you still need to make <filter> like an > object as well: > > > <xsl:filter classid="java:ConvertPrice"> > > <xsl:arg name="..... > > because you could maybe do something like: > > <xsl:object name="MyFilter" classid="MyFilter.class"/> > <!-- MyFilter.class has a method ConvertPrice(DocumentFragment frag) --> > ..... > <xsl:filter type="text/javascript" script="MyFilter.ConvertPrice(this)"> > > So I would say scripting was a first priority. Using objects probably flows naturally from > this if there is DOM support. The key difference is state. With an object-style filter there is no shared state between separate filter objects. With a script-style filter there is a shared context that is used for the evaluation of all script fragments. An object-style filter is something that I could imagine implementing in an interactive non-batch environment such as a WYSIWYG editor, because the effect of the filter is localized to the subtree of the result that the xsl:filter element contains. With a script-style filter, the script code has global side-effects, and I think it would be very difficult to make this work in a non-batch environment. James XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[no subject], Flow Simulation | Thread | xsl:counter-scope, Paul Spencer |
[no subject], Flow Simulation | Date | Re: XSL Counters list order?, James Clark |
Month |