[
Lists Home |
Date Index |
Thread Index
]
> Nice, but let's change "Java" to "native", where native is defined
> by the language being used. ;-)
Oh, ok if you must :)
> Yes! This in particular is a sore point for me. I'm able to do it
> in Python, but I have to know which DOM implementation I'm using so I
> can do the right magic for the implementation.
Well my helper routine just makes it *appear* as if the element is being
renamed. In fact a new element is created, and the children of the
original element moved over. Probably not very efficient, but it was
good enough at the time.
> A helper routine does help, but doesn't give a "good feeling". The reason for not allowing
> tagName to be changed has been explained to me (that an implementation
> may use different classes to implement different elements), but
> doesn't seem sufficient (allowing tagName to be mutable or throw some
> exception may be tolerable, and being able to ask the DOM
> implementation if it allows general element renaming would be useful.
I wasn't aware of that. Interesting. Presumably this is to allow custom
DOM implementations (e.g. for SVG) to substitute their own implementations?
Is this feature used in practice?
Seems like there are various ways this functionality could be retained, but
still allow renaming to take place. Worse case scenario is that a rename ends up
creating a new kind of object, but this could still be transparently handled by
the DOM impl I think.
Thinking about it, if this feature *is* to allow different classes for differently named
elements, then presumably this is to allow these classes to have additional
behaviour. You're going to need a cast or similar to get an alternate reference,
so this could be handled just as well by delegation I think. Or have I gone all
Java-centric again :)
Cheers,
L.
|
