Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Effective DOM (was RE: Effective XML)
 Leigh Dodds writes: > Oh, ok if you must :) Oops, did my bias show? > 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. That's an implementation detail as far as I'm concerned, but means that all references to the old node are (effectively) invalid. Python generally approaches implemenation with a "we're all adults here" attitude, so typically allows setting of all attributes by any code; it takes real work to protect an attribute. It's then just a matter of how concerned the implementor is with "readonly" designations in the spec (and we see both ends of the spectrum in practice... heck, I've implemented both ends for the DOM!). As long as the DOM is written in Python (rather than for Python but in C or some other language), it's incredibly difficult to prevent Python code from modifying the underlying values that an implementor may use to to support tagName or any other DOM attribute. > 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? Yes; I would be surprised if many HTML DOMs don't do that! I've certainly considered using the technique in other situations as well -- it seems very reasonable. > 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. Yes, kinda. It would be very easy in Python, and I suspect relatively painful in Java. My first shot at it would be be to use proxies, but it's hard to proxy arbitrary derived classes in Java (consider that the actual interface is extended, and you want the proxy to behave as the specialized interface). > 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 :) Very! I have a proxy type for Python which can have it's referent changed, and the behaviors of the proxy change accordingly; it can lose and gain attributes easily. I'd expect this wouldn't be hard with JavaScript either -- a proxy object which wraps the actual object is a pretty fundamental thing in the JavaScript model (or it was the last time I read the spec; not recently). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
