- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Tue, 24 Jan 2006 17:59:42 +0100
- To: Cyril Concolato <cyril.concolato@enst.fr>
- Cc: www-svg@w3.org, Jean-Claude Moissinac <moissinac@enst.fr>, Jean Le Feuvre <jean.lefeuvre@enst.fr>
* 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! 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? 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. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Tuesday, 24 January 2006 17:05:38 UTC