Re: New XPath extension function called xslt(), versus XSLT as an action


Well, at least for XSLTForms, there is an appreciable difference in 
speed because, with an action, the text result has to be parsed and 
stored in specific DOM-like objects then serialized in Javascript. It's 
also much easier for developers not to have to write actions on events.

Wouldn't it be more interesting to consider dependencies with ancestors: 
if a node has changed, all its ancestors have too??



John Boyer a écrit :
> Hi Alain,
> Agreed the ability to call the transform as a function is 
> syntactically easier.  Not sure why there is any appreciable 
> difference in speed.
> Regarding dependencies, though, yes I think you are missing where the 
> dependencies are coming from.
> The output of the xslt might be a string, but the input to be 
> transformed would be the *root* of some data node.  The function 
> implicitly consumes all nodes in the subtree, but the parameter refers 
> only to the root node, so the XPath containing xslt() would not have 
> any dependencies on all the nodes.
> If you call the xslt() function someplace that is ephemeral, like a 
> submission ref, then it's OK because the result is obtained at a point 
> in time, used and then discarded.  There is no long term tracking of 
> dependencies on the XPath.  But an XPath in a UI binding, for example, 
> is different.  The XForms processor is expected to make the UI reflect 
> the state of the model.  So any change within the entire data subtree 
> should reasonably cause your <xf:output value="xslt(data/root)"/> to 
> be updated by running the transform again.  And when that doesn't 
> happen, it looks like a language defect.
> Cheers,
> John M. Boyer, Ph.D.
> STSM, Lotus Forms
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail:  
> Blog:
> Blog RSS feed: 

Received on Friday, 23 April 2010 21:03:31 UTC