Re: Using templates instead of script to render custom content

Hi Antoine.

Antoine Quint:
> >  - XSLT is a proven XML transformation language.
> 
> Indeed. However, I would add it has been especially proven in a 
> different context, more oriented around batch-process, run-once 
> transformations, just to make things clearer. I like XSLT, I'm just not 
> used to it being used in dynamic environments and I'm not sure it's 
> that that proven in that context.

True, but I think there is potential for it to be used in incremental
situations.  See, for example, http://www2002.org/CDROM/refereed/321/ .

> >  - animation could be specified on attributes of custom elements and
> >    the "right thing" would happen.
> 
> That's interesting. This is a problem I have been thinking about for a 
> while in the RCC context and it's not easy to solve. The SMIL Animation 
> specification does not specify a way to interact with a SMIL engine and 
> feed it information on what a custom attribute's data type is and how 
> it should behave during an animation. In fact, you can't even tell a 
> SMIL engine what attributes can or cannot be animated. This all has to 
> be hard-coded in a host engine, as in an SVG implementation in 
> conformance with the SVG implementation which says what is and what 
> isn't animatable. Say I have this SVG fragmentt:
> 
> <ui:button width="200">
>   <animate attributeName="width" by="50" dur="1s" begin="mousedown" 
> fill="freeze" />
> </ui:button>
> 
> Technically, the "begin" value can be defined since RCC/LiveTemplates 
> define how a shadow tree's events are routed back to the custom element 
> instance. However, go figure how your SVG implementation will know how 
> to animate your button's width, how is it supposed to know that your 
> button's width is expressed as a float value?!?  You could argue that 
> in this case your implementation could "guess" it, but there are a 
> variety of data types that can't be guessed and there has to be a way 
> to define how incrementation would work on such and such data types.

Yep, things like this would have to be worked out.  My implementation
isn't a complete solution, just a prototype!  Plus, I haven't
implemented any animation support at all.  I think though, that in my
CSVG framework, some system of typing custom elements' attributes will
have to be done, and this is what could be used to hint at what sort of
animation can be done.

> Additionally, animation (including those done with the <set/> element) 
> do not work on the DOM values of attributes but on their animated 
> values, there would have to be specific directions in the SVG 
> specification to say that the same kind of refreshes happen for DOM and 
> animated value changes.

Yup.  One thing I was considering is using my expression based
attributes similarly to animations, for example:

  <rect x="0" y="0" width="100" height="100">
    <constraint attribute="x" value="id('r')/@x"/>
  </rect>

This then would parallel how animation is handled in current SVG.  It
also has the advantage of supplying default values if there is no
support for my constraint extension.

In fact, if the idea was generalised to allowing animation to support
expressions, then the constraints could just be another form of
animation.

  <rect x="0" y="0" width="100" height="100">
    <animateExpression attributeType="XML" attributeName="x"
      expression="id('r')/@x"/>
  </rect>

> There is no way an XSLT-based mechanism makes it any easier to 
> accomplish this than any other mechanism as there is no way to animate 
> non-SVG attributes today. If you have proposals on how to accomplish 
> this, I'd be happy to read it.

Without expression based attributes, I agree.  That's the angle I was
coming from though, so sorry if I confused you.

With expression based attributes though, animation could be specified in
a completely different way, using some time variable.  For example:

  <rect x="time()" y="0" width="100" height="100"/>

where time would be a function that returned the current animation time
in seconds.  This would allow for all sorts of interpolations not
supported in SMIL.  This style of animation might be easier to integrate
with the template stuff than SMIL's.

> I took a look at your examples. I think your mechanism would be fit for 
> simple standalone widgets, but this approach has some limitations for 
> larger-scale projects. Part of what makes RCC "popular" so far (besides 
> an implementation :) is that it fits in a DOM-based environment that's 
> very good for scripting integration. A popular and well-proven approach 
> to designing custom widgets, back from pre-RCC days and greatly 
> simplified by RCC, is to have an ECMAScript (or whatever other 
> scripting language) class that handles a particular custom XML element. 
> Of course, this class architecture can help having some inheritance and 
> cleanly share functionalities between different custom elements. 
> Additionally, using a controller object, a context can be easily 
> maintained for complex widgets that involve state tracking etc without 
> having to store data in the XML tree.

Yes, object orientation is good for this sort of thing, especially as
authors might like to think of their custom elements as objects.  That
is a disadvantage of my approach.

The best reason why I think something like templates+expressions could
be better than script for implementing RCC is the automatic dependency
tracking.  I imagine that if everyone is writing their script to handle
custom elements that they will have to handle mutations on them
manually, by attaching event handlers and then manipulating the DOM
when the event is fired.  This sort of code is going to be common to all
RCC scripts if authors want their custom elements to be modifiable and
the changes to be propagated to the shadow tree.  With the expressions
and dependency tracking, this sort of thing would happen automatically,
so the author doesn't have to worry about it.

> Also, there is clean integration with DOM Events, so that custom events 
> can be triggered from the DOM implementation, and SVG 1.2 should 
> closely integrate with DOM Level 3 Events so that custom and namespaced 
> events can be created and dispatched. Your button example relies 
> exclusively on attribute-based event listeners, which are implicitly 
> deprecated by the XML Events specification and the current efforts of 
> its SVG 1.2 integration, although I suspect your samples could be 
> reworked to use XML Events. Anyway, not using XML Events you are forced 
> to use methods that imply usage of eval(), which is bound to attract 
> flames from a good part of the community (I'll let Jim Ley comment 
> further) including Java folks who are not necessary "blessed" with this 
> functionality.

Sure, the eval thing is really hacky.  I just used it in my examples
because 1) my prototype didn't have the ability to handle
non-XPath-expressions for custom element attributes, and 2) I didn't
think going to the effort of creating DOM events and firing them off was
useful for the purposes of the example.  I would, of course, prefer
proper event handling/dispatching.

> Additionally, and for what it's worth, note that the RCC approach 
> involves a lot less specification work than your approach as there is 
> no need to defined additional XPath functions for things like bbox() 
> and the likes that I see you use in your samples. RCC leverages the DOM 
> specification further.

That is probably the greatest obstacle.  In the beginning of my project
I was wondering whether to use ECMAscript for the expressions but I
decided that XPath was just too useful.  Also it is more consistent with
the template stuff.  If attribute expressions used the DOM, though,
you'd get examples like:

  <rect x="document.getElementById('r').getAttribute('x')" y="0"
    width="100" height="100"/>

which is quite verbose.  Also tracking dependencies through the script
would be a nightmare compared to the XPath stuff.

At the moment I am not completely happy with the syntax I have
(lots of accessor functions).  I will probably end up having (mostly
implicit, sometimes explicit) type information about elements'
attributes so that they can be referred to just with XPath locations.
That is,

  <rect x="id('r')/@x" y="0" width="100" height="100"/>

instead of

  <rect x="x(id('r'))" y="0" width="100" height="100"/>

> The good news is that there has been considerable work from within the 
> working group to try and concialiate the RCC and LT approach, and all 
> of this should be detailed in the next working draft.

I'd certainly be interested in knowing which direction it's going.

Thanks,

Cameron

-- 
Cameron McCormack
|  Web: http://mcc.id.au/
|  ICQ: 26955922

Received on Tuesday, 4 November 2003 18:06:05 UTC