Re: Using templates instead of script to render custom content

"Kim Marriott" <Kim.Marriott@infotech.monash.edu.au> wrote in message
news:BBCEC885.4DD9%Kim.Marriott@infotech.monash.edu.au...
> B) Modify the custom element attributes and regenerate the shadow tree.
This
> will be considerable simpler: simply modify one or two attributes, but has
> the potential disadvantage that it is very expensive: regenerating all
> shadow trees for every time step in an animation seems prohibitively
> expensive.

Implementations of RCC that I've seen do not regenerate the entire
shadowTree for such modifications, indeed I'm not sure it's possible, an RCC
element needs to catch mutation events and act on those, changing attributes
wouldn't as I see it generate bindBegin/bindEnd events where the shadowTree
changes are normally made, it would just generate mutation events.

> C2) Extend SVG with custom elements which do not provide the full-power of
> script but that are designed to support incremental update of shadow tree
> attributes and elements. This is the approach we have taken and modelled
our
> extension on XSLT since this seems the closest relevant standard.
> C3) Use a reduced form of XSLT which can be efficiently incrementally
> evaluated and use this to generate the SVG from the custom elements. This
> requires little modification to SVG but does mean identification and
support
> for such incremental or dynamic XSLT.

Or the existing method of having Mutation events which the RCC script can
respond to and perform the changes.  This seems much more elegant, as it
means that instead of having XSLT generating elements (when all you want is
an attribute change) you just have the script modifying the elements, it's
in many ways like your A suggestion before where you acting on the
shadowTree, but you are not of course doing it externally from the RCC
component so you're version safe, and there's no lack of performance.

My concern with putting XSLT and XPath and the kitchen sink is that you're
raising the bar of implementors, and people trying to learn the technology
for little real benefit, just a slightly neater way to do some things, and
unless everything is implemented, we're not actually going to be able to use
all of them - and I would like SVG 1.2 to become a Rec some time soon (and
I'm certainly going to ensure that everything in SVG 1.2 is actually
implemented before Rec)

Jim.

Received on Wednesday, 5 November 2003 04:35:33 UTC