Re: Request For Feedback: Traits

Hi Bjoern,

Bjoern Hoehrmann a écrit :
> * Cyril Concolato wrote:
> 
>>So, what we do not like about Traits. The API currently has 3 sets of methods (see attached figure):
>>- get/setAttribute(NS) methods which return the string representing the specified value. 
>>- get/set*Trait(NS) methods which return the typed computed value, 
>>- get*PresentationTrait methods which return the typed presentation value, 
> 
> 
> Thanks for this excellent feedback! 
Thank you. I appreciate that you find our feedback interesting.

> I have a question though: you say
> there should be only one of these methods; could you say again why
> having getPresentationTrait and getAttributeNS would be problematic
> in your implementation? It seems getPresentationTrait is easy as the
> value is more or less directly available from the rendering tree, and
> you said what getAttributeNS would return is stored in this animation
> structure, so having these two access methods shouldn't be difficult,
> no?
To clarify the complexity of the getters, here is a classification from simple to more complex access methods:

1) as you pointed out, getPresentationTrait when animation is running is the easiest getter to implement (in our implementation), because the value in our 'rendering' tree is exactly the presentation value and no serialization is needed.

2) getAttributeNS when no animation is running, is a slightly complex because of serialization, but access is also simple because the value in the rendering tree is the specified value 

3) getAttributeNS, if animation is running, is even more complex because we need to retrieve the specified value from the animation structure. However, this structure is accessible without tree traversal, so this is not a big issue. You would have to check if an animation is targetting this attribute to detect if the current value in the rendering tree is the specified or the presentation value. Then, you would have to get the animation structure and finally retrieve the value. It's doable but would be inefficient (maybe some optimisations could be done, I have not thought about that yet).

4) if no animation is running, getPresentationTrait is equivalent to getTrait and returns the computed value. In our implementation, the computed value is not stored in the rendering tree, but is a computed through inheritance during tree traversal at each rendering cycle. It is the most complex accessor because a tree traversal down to the accessed attribute is required for inheritance. Of course, it is as simple as 1) if the attribute is not a property.

So, the answer to your question is not that simple. It depends on whether animations are running or not and whether inheritance is used or not. The problem is that a single method can be efficient or slow mainly depending on inheritance. We believe some optimisations can be done to improve the speed of these methods but it would penalize the memory consumption. The classical tradeoff.

> As you point out, getPresentationTrait and getTrait return the exact
> same value unless animations are involved. As I pointed out earlier,
> considering this I don't see use cases for getTrait, if you ever have
> the strange case where you need it, you can construct the value using
> getAttributeNS or (better) simply call getPresentationTrait at the
> right point in time and store the value, so I'd be happy to see them
> go.
We agree with these statements, that getTrait and getPresentationTrait could be merged in a single typed accessor.

To summarize, our proposal is to have only one typed getter which returns the presentation value, or the computed value if no animation is running, or the specified value if no inheritance is applied. But there should be a warning for authors that efficiency of this method is implementation-dependant in case of animation and inheritance.

Best regards,

ENST Team
-- 
Dept. Comelec
Ecole Nationale Supérieure des Télécommunications, Paris
46, rue Barrault 75013 Paris
Tel: +33145817991    Fax: +33145804036

Received on Wednesday, 25 January 2006 09:53:56 UTC