Closed
Bug 278257
Opened 20 years ago
Closed 20 years ago
Need a way to get the bound type of an instance node
Categories
(Core Graveyard :: XForms, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: doronr, Assigned: allan)
References
Details
Attachments
(2 files, 1 obsolete file)
2.43 KB,
patch
|
Details | Diff | Splinter Review | |
16.23 KB,
patch
|
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
In the MDG, for schema validation, I need to get at the value and type, and it seems that getting the bound type is currently impossible. <beaufour> I think I misuse the type attribues as an "any-type" thing in GetNode() or something <beaufour> and, the AddMIP()-calls in nsXFormsModelEngine needs to do specific stuff for the type, including changing the AddMIP-call itself, and nsXFormsMDGNode()
Reporter | ||
Comment 1•20 years ago
|
||
Note that we also need a way to get to the model element, as nsXFormsModelElement has a nsCOMPtr<nsISchemaLoader> mSchemas; which stores the external schemas the model references.
Summary: Need a way to get the bound type of an instance node → Need a way to get the bound type of an instance node
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•20 years ago
|
||
Changed nsXFormsModelElement::ProcessBind(), to support type info. It now sets the @type and @p3ptype attributes on the instance nodes, so they can be retrieved by probing the nsIDOMElement. It also dispatches the proper xforms-binding-exception events. I also added a not about the use of eModel_type in nsXFormsMDGEngince, and changed the parameter type of AddMIP to use the enum while I was at it. Two couple of questions: 1) Instead of setting the attributes via nsIDOMElement, I should use nsIContent::GetAttr() instead, should be faster and lead to more simple code. But then I need to get the namespaceid, etc. What do you say? 2) We were not using the XPath expressions saved in the property, so I deleted it. We could save it there and use it in EvaluateNodeBinding. Should we? (on another bug then)
Attachment #171512 -
Flags: superreview?(darin)
Attachment #171512 -
Flags: review?(doronr)
Reporter | ||
Comment 3•20 years ago
|
||
Comment on attachment 171512 [details] [diff] [review] Support type and p3ptype in ProcessBind() Please add a comment that we shouldn't be setting the type on the instance data more than once, that was a bit confusing. Also per IRC, nsIContent should not be used because it may change.
Attachment #171512 -
Flags: review?(doronr) → review+
Reporter | ||
Comment 4•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #171512 -
Flags: superreview?(darin)
Assignee | ||
Comment 5•20 years ago
|
||
I incorporated Doron's comments, his ValidateNode() function, and removed the nsIContent comment. I also changed ProcessBind() to return nsresult. It should have done that a long time ago...
Attachment #171512 -
Attachment is obsolete: true
Attachment #171629 -
Flags: superreview?(darin)
Assignee | ||
Comment 6•20 years ago
|
||
*** Bug 257180 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
Comment on attachment 171629 [details] [diff] [review] Review comments incorporated >+ /** >+ * Pointer to next nsXFormsMDGNode with same nsIDOMNode, but different >+ * MIP type (mType)*/ nit: add a space before the */ >diff -X patch-excludes -upN -U8 xforms.newbranch/nsXFormsModelElement.cpp > } >- >+ > // 5. dispatch xforms-rebuild, xforms-recalculate, xforms-revalidate nit: remove random whitespace addition sr=darin
Attachment #171629 -
Flags: superreview?(darin) → superreview+
Reporter | ||
Comment 8•20 years ago
|
||
allan - I tried applying this to the trunk (with the landed xforms branch) and it doesn't apply - manually trying to fix it shows it relies on missing variables for example. Seems something changed (bug 265931 perhaps) that broke this.
sorry, I had 265931 in my list of stuff that was in the branch, but it was probably an older version of the patch in the branch. When I made the trunk I probably grabbed the latest patch that didn't get sr'd until today.
Assignee | ||
Comment 10•20 years ago
|
||
(In reply to comment #9) > sorry, I had 265931 in my list of stuff that was in the branch, but it was > probably an older version of the patch in the branch. When I made the trunk I > probably grabbed the latest patch that didn't get sr'd until today. Something went wrong, that's correct. Nevertheless I've fixed it now, and checked it in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•