Last Comment Bug 339217 - insert should generate new id for xsd:ID nodes
: insert should generate new id for xsd:ID nodes
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: ---
Assigned To: xforms
: Stephen Pride
Depends on: 338823
  Show dependency treegraph
Reported: 2006-05-25 07:18 PDT by Allan Beaufour
Modified: 2016-07-15 14:46 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

Testcase (2.23 KB, application/xhtml+xml)
2006-05-25 07:20 PDT, Allan Beaufour
no flags Details
Testcase (using attributes) (2.06 KB, application/xhtml+xml)
2006-05-30 09:36 PDT, Allan Beaufour
no flags Details
Work in progress (5.98 KB, patch)
2006-05-30 09:40 PDT, Allan Beaufour
no flags Details | Diff | Splinter Review
Patch (16.58 KB, patch)
2006-05-31 04:18 PDT, Allan Beaufour
no flags Details | Diff | Splinter Review

Description Allan Beaufour 2006-05-25 07:18:38 PDT
Insert should generate unique IDs when inserting new data:
"In this process, nodes of type xsd:ID are modified to remain as unique values in the instance data."
Comment 1 Allan Beaufour 2006-05-25 07:20:06 PDT
Created attachment 223291 [details]
Comment 2 Allan Beaufour 2006-05-30 07:43:18 PDT
There is something slightly wicked about this:
If the types are set via a schema, then rebuild needs to have run for the types to be set (bug 338823). That's mighty fine, if it were not for deferred actions. Then we have to defer the updating of newly inserted nodes until rebuild actually runs (and before recalculate, or new values will not be used). Ouch. I might do a follow up bug for that one.
Comment 3 Allan Beaufour 2006-05-30 09:36:20 PDT
Created attachment 223793 [details]
Testcase (using attributes)
Comment 4 Allan Beaufour 2006-05-30 09:40:03 PDT
Created attachment 223794 [details] [diff] [review]
Work in progress

I'm not sure it's ready. It could be, but gotta go now.
Comment 5 Allan Beaufour 2006-05-31 03:45:19 PDT
There's a couple of unknowns about how this should be done (at least for me):

I might do a some-of-the-way patch for 0.6 though.
Comment 6 Allan Beaufour 2006-05-31 04:18:17 PDT
Created attachment 223909 [details] [diff] [review]

It would be a good feature to have in 0.6, so here's a patch that "assumes" a few things for the questions in comment 5:
1) the id modification happens between rebuild and recalculate
2) the id is not necessarily unique, but for 99.9% of the cases it is. I use "moz-xf-id" as a prefix to not clash with XSL-generated IDs.
3) modification does not adhere to the readonly MIP (just as calculate does not either)
4) deferred actions are not handled

Codewise I have two issues:
1) I'm a bit unsigned about the pointer conversion. It should be alright, but I'm not 100% sure.
2) I'm pondering massaging the node directly through nsINode instead, to avoid all the DOM calls, but then again, it's better to rely on the DOM calls.

If you are ok with the assumptions, I'll post a follow up bug for fixing them / assuring that they are correct.
Comment 7 Allan Beaufour 2006-05-31 09:03:44 PDT
Comment on attachment 223909 [details] [diff] [review]

clearing review request... the modification might happen during the cloning, not after....
Comment 8 David Bolter [:davidb] 2016-02-04 12:21:04 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.