Closed
Bug 278370
Opened 20 years ago
Closed 20 years ago
Restructure access to MDG in nsIModelElementPrivate.idl
Categories
(Core Graveyard :: XForms, defect)
Core Graveyard
XForms
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: allan, Assigned: allan)
References
()
Details
Attachments
(1 file, 4 obsolete files)
|
19.68 KB,
patch
|
bryner
:
superreview+
|
Details | Diff | Splinter Review |
Quoting smaug on bug 265467: >>+ readonly attribute nsXFormsMDGEngine MDG; >Hmm, using non-interface class in an interface.
| Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Comment 1•20 years ago
|
||
Hmmm, there are two reasons the MDG is there: 1)To allow access to Get/SetNodeValue(). These can easily be proxied via nsIModelElementPrivate. 2) To allow access to nsXFormsNodeState. This will not be necessary when bug 271720 is fixed, as the control can then access :read-only, :valid, etc.
Depends on: 271720
| Assignee | ||
Comment 2•20 years ago
|
||
I removed the direct MDG access in nsIModelElementPrivate. Instead I let it proxy set/getNodeValue() for the MDG. So mMDG is gone from nsXFormsControlStub, but instead I cache a pointer to the model. We use it a lot. I also added a RemoveFormControl() to its OnDestroyed(). nsXFormsControlStub also reads the read-only-state of itself from the attribute, as it should. nsXFormsNodeState should never have been passed to it in the first place. My bad.
| Assignee | ||
Updated•20 years ago
|
Attachment #171631 -
Flags: review?(smaug)
Comment 3•20 years ago
|
||
Comment on attachment 171631 [details] [diff] [review] Patch v1 > NS_IMETHODIMP > nsXFormsUploadElement::Blur(nsIDOMEvent *aEvent) > { >- if (!mInput || mBoundNode || mMDG) >+ if (!mInput || mBoundNode) Shouldn't this be: if (!mInput || !mBoundNode || !mModel) ? Check similar thing also in XFormsInputElement::Blur(). With that r=me
Attachment #171631 -
Flags: review?(smaug) → review+
| Assignee | ||
Comment 4•20 years ago
|
||
(In reply to comment #3) > (From update of attachment 171631 [details] [diff] [review] [edit]) > > NS_IMETHODIMP > > nsXFormsUploadElement::Blur(nsIDOMEvent *aEvent) > > { > >- if (!mInput || mBoundNode || mMDG) > >+ if (!mInput || mBoundNode) > > Shouldn't this be: if (!mInput || !mBoundNode || !mModel) ? > Check similar thing also in XFormsInputElement::Blur(). Indeed it should. Sloppy coding from me, sorry.
| Assignee | ||
Comment 5•20 years ago
|
||
+ smaug's comment
Attachment #171631 -
Attachment is obsolete: true
Attachment #171736 -
Flags: superreview?(darin)
| Assignee | ||
Updated•20 years ago
|
Attachment #171736 -
Flags: superreview?(darin)
| Assignee | ||
Comment 6•20 years ago
|
||
Updated patch for trunk.
Attachment #171736 -
Attachment is obsolete: true
Attachment #171867 -
Flags: superreview?(darin)
| Assignee | ||
Comment 7•20 years ago
|
||
Comment on attachment 171867 [details] [diff] [review] Patch v2 for trunk I sense that Darin has enough to do ftm.
Attachment #171867 -
Flags: superreview?(darin) → superreview?(bryner)
Comment 8•20 years ago
|
||
I am currently using nsIModelElementPrivate::GetMDG() to get at the nodestate of a domNode (code is not checked in) for submission to check if all required nodes have a value. I use he nodestate to check if a node is required, and it seems this patch will break that. Is there another way?
| Assignee | ||
Comment 9•20 years ago
|
||
(In reply to comment #8) > I am currently using nsIModelElementPrivate::GetMDG() to get at the nodestate of > a domNode (code is not checked in) for submission to check if all required nodes > have a value. I use he nodestate to check if a node is required, and it seems > this patch will break that. Is there another way? argh. Which bug is that? I'll look at it and see.
| Assignee | ||
Comment 10•20 years ago
|
||
Attachment #171867 -
Attachment is obsolete: true
Comment 11•20 years ago
|
||
Comment on attachment 171867 [details] [diff] [review] Patch v2 for trunk Removing review request until allan and doron have worked out access to the MDG object.
Attachment #171867 -
Flags: superreview?(bryner)
Comment 12•20 years ago
|
||
actually, Allan an I talked and we agreed that my code can be moved to the Model code and thus doesn't need getMDG() anymore.
| Assignee | ||
Comment 13•20 years ago
|
||
(In reply to comment #12) > actually, Allan an I talked and we agreed that my code can be moved to the Model > code and thus doesn't need getMDG() anymore. Doron, could you put the bug with your code on the dep.list for this bug?
Comment 14•20 years ago
|
||
The bug is bug 279449, not sure if this one depends on it though.
| Assignee | ||
Comment 15•20 years ago
|
||
Doron is not using GetMDG, so here's an up-to-date patch. Rerequesting sr.
Attachment #172499 -
Attachment is obsolete: true
Attachment #172792 -
Flags: superreview?(bryner)
Comment 16•20 years ago
|
||
Comment on attachment 172792 [details] [diff] [review] Updated to current CVS > PRBool > nsXFormsControlStub::GetReadOnlyState() > { > PRBool res = PR_FALSE; >- if (mBoundNode && mMDG) { >- const nsXFormsNodeState* ns = mMDG->GetNodeState(mBoundNode); >- if (ns) { >- res = ns->IsReadonly(); >- } >- } >+ if (mElement) { >+ mElement->HasAttribute(NS_LITERAL_STRING("read-only"), &res); >+ } This suggestion isn't specific to this patch, as it would require changing a couple of other locations... how about changing this to __moz_readonly and adding a comment that we should not be modifying the document DOM? Same for the other attributes. I'm worried that if we ship a beta release with these attributes that people will begin using them and we'll never be able to get rid of them in favor of the CSS pseudoclasses. Anyway, sr=me for this patch since you're not introducing new attributes or anything.
Attachment #172792 -
Flags: superreview?(bryner) → superreview+
| Assignee | ||
Comment 17•20 years ago
|
||
(In reply to comment #16) > This suggestion isn't specific to this patch, as it would require changing a > couple of other locations... how about changing this to __moz_readonly and > adding a comment that we should not be modifying the document DOM? Same for > the other attributes. > > I'm worried that if we ship a beta release with these attributes that people > will begin using them and we'll never be able to get rid of them in favor of > the CSS pseudoclasses. Good point, Or rather __moz_TEMPORARY_readonly, or something _really_ obvious? > Anyway, sr=me for this patch since you're not introducing new attributes or > anything. Ok thanks, I'll check it in later.
| Assignee | ||
Comment 18•20 years ago
|
||
Checked in. Also removed bug 271720 dependency ... what was it doing there?
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
•