![](https://secure.gravatar.com/avatar/b47d036b8f12e712f4960ba78404c3b2.jpg?s=120&d=mm&r=g)
MenTaLguY wrote:
On Wed, 26 Mar 2008 12:51:05 -0300, "bulia byak" <buliabyak@...400...> wrote:
Mental: as I remember you mentioned that to fix this, we need to have the clipboard as an SPDocument. This has just been done on trunk :)
Yes. XML::Nodes don't know anything about hrefs to be able to update them, but SPObjects do.
What's the next step?
It depends a bit on the architecture of the new clipboard code, which I haven't looked at in much detail yet.
Chris, what do you think?
-mental
I was concerned by the id conflict problem too (in fact, I was hit by it several times when editing Gartoon icons). The problem is that while finding a new unique id when pasting a def is easy, there is no easy way to change all the references in the document to a given ID. At present the only ways I can think of to do this from the clipboard code would be: a) iterate over all the items in the SPObjects and all its attributes and CSS properties that can refer to other objects, and replace mentions of the modified ID. b) do a text search/replace over a string containing the XML. Actually I think b) would work much better, because a) is prone to omissions. I'll try to pull off this hack shortly so that we have a fully working clipboard. The right way would be to do what is proposed in this roadmap item:
Create an SPObject API for tracking references and avoiding id clashes on import and interdocument copy/paste. What we need are a void SPDocument::importCopies([set of SPObjects]), and an [set of SPObjects] SPObject::dependencies() method.
The only problem with this roadmap item is that it omits an important point - there is little problem in obtaining the dependencies of a given object, and this is what _copyUsedDefs() in current clipboard code does (however, it checks all the possible ways a def can be referenced, which isn't optimal either). The problem is getting the dependent objects of a given def. Therefore the above interface has to be extended with a third method like auto_ptr<std::list<SPObject*> > SPObject::dependentObjects(). Implementing this thoroughly would mean modifying or at least checking all the code that creates or removes defs from the document. However, everything the clipboard needs is to have this data valid just after it is loaded from the file. I don't have a complete public API proposition ready yet, much less a clear idea of how should this be implemented, but generally both dependencies and dependents should be tracked.
Regards, Krzysztof (Chris) Kosiński