Re: Request For Feedback: Traits

On Jan 17, 2006, at 19:59, Jeff Schiller wrote:
> I am not an implementor, I am a web developer who has had a little  
> experience developing with SVG 1.1.  Can I ask the SVG WG or others  
> who may know the answer why the SVG 1.1 DOM was not brought into  
> SVGT 1.2?  Will the SVG 1.1-style DOM be brought into SVG Full  
> 1.2?  Given that the SVG 1.1 DOM provided strong typing, access to  
> individual components and avoided string parsing why was the new  
> Trait mechanism developed?
>
> Why is
>
> a)  someCirc.cx.baseVal.value += 5.4;
>
> better than
>
> b)  someCirc.setFloatTrait("cx", someCirc.getFloatTrait("cx") + 5.4);

I think you meant "worse than" (or "not as good as"). The problem  
that people (not necessarily myself) had with (a) was the sheer  
number of classes required to represent it. First someCirc needs to  
be an SVGCircleElement (or failing that you need cx accessors on all  
SVGElements), which in turn means you now need to have a large bunch  
of SVGFooElement classes. Then you need a class for cx:  
SVGAnimatedLength. This also translates to an explosion of other  
classes, first all the SVGAnimatedFoo for each data type, and then  
the SVGFoo for the non-animated versions. And then in a number of  
cases (as in fact the above) baseVal needs to have its class, one for  
each non-simple type that can be animated.

Even assuming Tiny, that's a big ugly bunch of classes that you've  
got to try to fit on a small phone. The footprint will be noticeable,  
especially since you're not on your own but part of a larger stack.

The idea that all of the above could be of type "SVGMagical" and auto- 
generate the proper access by catching the default message was  
floated for a while, but it doesn't work because we have to also work  
on Java, which doesn't support object-orientation :(. Javascript  
doesn't either but it can be emulated by the back-end.


Strawman (not necessarily representing my opinion):
===================================================
Maybe there's a mid-point whereby we can drop Traits in Tiny 1.2, and  
just leave it as an advantage of the folks who use JSR-226. Of  
course, we don't lift anything from the full SVG DOM either, as that  
would be too heavy. Instead, we stick to getAttributeNS and  
setAttributeNS but specify require (or very strongly recommended)  
normalisation of the values so that what is returned is easiest to  
process and scripts don't have to handle the endless variety of  
options that may be available to them. That, and perhaps a few  
helpers, e.g. to parse a colour into an SVGColor. This sort of meets  
the requirement for typed access midways (data is normalised and can  
be upgraded to type easily) while reusing mostly what already exists.  
It has the default of inefficiency (you'll be converting to and from  
string every other line of code).

Thoughts? Answers on a postcard.

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/

Received on Wednesday, 18 January 2006 09:14:33 UTC