In order to remove the last of the veto callbacks (the only one used, in only one place), I went ahead and rewrote SPDocument::getObjectByRepr() so it didn't rely on ID lookups, then removed the change attribute veto callback.
Two side-effects of this:
1. it is now possible to remove the id attribute from an element
This shouldn't cause any problems, as I laid the groundwork for id-less operation a long time ago (this has been planned for a while). Note that objects still get ids by default.
2. manually setting a conflicting id now causes the original object to get a new id, rather than disallowing the change
This should always have been at least possible through the XML editor. I'm not as sure about the properties dialog; if we decide it's best to disallow setting a conflicting ID again we can implement a check in the dialog.
I think both changes are more in line with user expectations anyway.
Test and let me know if I missed any breakage. I tried to be conservative about the change.
-mental
On Sun, Jan 16, 2005 at 02:34:33AM -0500, MenTaLguY wrote:
- manually setting a conflicting id now causes the original object to get a new id, rather than disallowing the change
Is there any way to get a status-bar message saying "old id renamed to blah" or something like that? When working on icons.svg, sometimes I didn't know if the name I was assigning already existed or not, and it was nice to have some kind of feedback about it. (Although I prefer the new renaming behavior.)
On Sun, 16 Jan 2005 02:34:33 -0500, MenTaLguY <mental@...3...> wrote:
- it is now possible to remove the id attribute from an element
So SPDocument::getObjectByRepr() won't work on it anymore? What is the preferred way to get at an element if not by id?
- manually setting a conflicting id now causes the original object to get a new id, rather than disallowing the change
You mean, some entirely different object that happens to have the same id will be renamed? I'm not sure it's a nice thing to do, especially without warning. At least in the places where this is accessible via UI (XML editor, obj props) there must be checks and warnings about this.
On Sun, 2005-01-16 at 15:38, bulia byak wrote:
On Sun, 16 Jan 2005 02:34:33 -0500, MenTaLguY <mental@...3...> wrote:
- it is now possible to remove the id attribute from an element
So SPDocument::getObjectByRepr() won't work on it anymore? What is the preferred way to get at an element if not by id?
It still works. This was the reason why I made a separate getObjectByRepr() (versus getObjectById()) and changed all the code that didn't directly depend on IDs to use it so long ago in the first place. [ SPDocument now maintains a direct SPRepr -> SPObject mapping table to support this, in addition to the existing id table. ]
We still need ids for URI references (e.g. clones or gradient references). Since we still give elements ids by default, users shouldn't be affected unless they explicitly remove an object's id. The object just wouldn't be accessible by URI reference until the user gives it an ID again.
In the long-term we'll also allocate IDs for SVG elements on-demand, so e.g. if an ID-less object is cloned it'll be assigned an ID automatically.
Note that allowing for non-ided elements was necessary, because we have to deal with non-SVG-namespace elements where id may not be the right name for XML ids, or IDs might not be part of the schema at all.
An example of such an issue is that we're sticking id= attributes in RDF, where the ID attribute is supposed to be rdf:ID if you have IDs at all (usually you won't). Now that we can support IDless elements it is easier to stop mangling RDF in this way.
Another issue this has fixed is that text (literal text, not the <text> element) and comment nodes no longer pollute the id namespace, since they are no longer assigned IDs.
- manually setting a conflicting id now causes the original object to get a new id, rather than disallowing the change
You mean, some entirely different object that happens to have the same id will be renamed?
Yes.
I'm not sure it's a nice thing to do, especially without warning. At least in the places where this is accessible via UI (XML editor, obj props) there must be checks and warnings about this.
The Object Properties dialog hasn't changed -- it still prevents a user from setting a conflicting ID.
As for the XML editor, I think there we must allow the user to do what they want, but a warning is not a bad idea; I'm just not sure how best to implement it yet.
-mental
participants (3)
-
bulia byak -
Kees Cook -
MenTaLguY