- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 08 May 2007 18:09:18 -0700
- To: "WAF WG (public)" <public-appformats@w3.org>
Currently the spec doesn't mention what happens when you clone an element that has XBL bindings attached to it. We can go two ways with this I think. Option A: Either we could basically say that nothing special happens. When .clone is called only the DOM element object is cloned. The new clone may or may not get the same set of bindings attached to it, but in any case no state is automatically carried over. Bindings that do want to propagate data to the clone could register a UserDataHandler which is notified about the cloning and could copy the data over. However a binding on the original element can't reach in to the same bindings private data on the clone, so there is no way to copy private information over. Option B: We state that when the original element is cloned so is all the bindings attached to it and all the data in all those bindings. The bindings that are no longer applicable (since the clone doesn't live in the same place in the DOM as the original element not the same CSS rules necessarily match) are removed the same way as normal. A xblLeftDocument call is also made if appropriate, i.e. if the original node lived in a document. In other words, to the clone it will look as if it was living inside the document with the exact same state as the original, and then removed from the document. We may also want to add some notification to tell the bindings on the clone that they were cloned, just in case there is some state that needs to be adjusted or they need to register somewhere. Option C: Something inbetween. When cloning we only clone the DOM element, but then we could notify all bindings on the clone that existed on the original element and give the notification function the inner object of the binding on the original element. Option D: Combination of B and C. Have notification with a default implementation that copies all the data and calls xblLeftDocument, but let the user override it to do whatever the user wants. Discussion: The advantage of A is that it's the easiest to implement. However it also means that you can't create bindings that deal well with cloning and still keep all their data private. Option B is very cool in that the binding doesn't have to do anything, it's all automatic. But it might be a lot of work to implement, though I don't think it'll be too bad. It is a bit scary to just unconditionally just clone the binding data though. It's also tricky to know how deep the data should be cloned, do you copy just the references and make them point to the same objects? Or do you do a deep clone of the private data? Option C is a compromise, the binding is still responsible for doing all the cloning, but it's given all the tools needed for it. D is basically what C++ does. I think D gets my vote as long as we can draft a good notification. / Jonas
Received on Wednesday, 9 May 2007 01:12:15 UTC