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•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•