349805 - updating instance via javascript doesn't work right

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, defect)

Description

[aaronr]

A form author should be able to update the value of a node in an instance document via javascript and as long as he doesn't change the document structure, he should only have to call model.recalculate(), model.revalidate() and model.refresh() to get the change reflected in the xforms controls.

Currently, we won't reflect the change unless the author calls rebuild() before rrr.

Looks like the problem is that we'll go through recalculate but it doesn't have any nodes to check (mMarkedNodes) so it just returns without doing anything.  From what I can tell, the only way that it has nodes to check is if we set the node value using nsXFormsModelElement::SetNodeValue (via xf:setvalue action on the form, nsXFormsDelegateStub::SetValue via our UIWidget XBL code, etc).

I think that we'll need to make nsXFormsModelElement::Recalculate (when it is called via JS) go through every node in its mMDG and mark them dirty (or more likely create a function in nsXFormsMDGEngine to do that) and then go through the normal mMDG.Recalculate().

Comment 1

[aaronr]

Attachment: testcase

Comment 2

[Allan Beaufour]

(In reply to comment #0)
> Looks like the problem is that we'll go through recalculate but it doesn't have
> any nodes to check (mMarkedNodes) so it just returns without doing anything. 
> From what I can tell, the only way that it has nodes to check is if we set the
> node value using nsXFormsModelElement::SetNodeValue (via xf:setvalue action on
> the form, nsXFormsDelegateStub::SetValue via our UIWidget XBL code, etc).

Sounds correct.
 
> I think that we'll need to make nsXFormsModelElement::Recalculate (when it is
> called via JS) go through every node in its mMDG and mark them dirty (or more
> likely create a function in nsXFormsMDGEngine to do that) and then go through
> the normal mMDG.Recalculate().

That should work, but ouch it will be expensive.

What is the status for mutation events? A better approach would be to listen for node change events, and then mark these nodes as dirty automatically.

Another approach would be for the JS author to use XForms methods to change the values...

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)

> What is the status for mutation events? A better approach would be to listen
> for node change events, and then mark these nodes as dirty automatically.

If they are quickly enough (how much quickly to be enough :)) then I guess too it's better approach. Who knows about it? Smaug?

Comment 4

[aaronr]

Mutation events would be more efficient in this scenario, but my personal feeling is that the number of forms that change instance values using script will be a very small percentage of the forms that we'll encounter.  And even on those forms, I assume that most of the instance data updates will still be done using the normal paths that we already handle.  Using mutation events will slow us down a little bit on every form.  So then we'd be slowing down everyone for the benefit of the few users of forms that use JS to change instance data.

So I'd say if you change instance data using JS, then you've got to suffer the consequences :-)  And if they are smart about it and lump multiple changes together before calling rrr, then the tradeoff won't be as bad, either.

Of course I'll go with whatever the group decides.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #4)
> Mutation events would be more efficient in this scenario, but my personal
> feeling is that the number of forms that change instance values using script
> will be a very small percentage of the forms that we'll encounter.  And even on
> those forms, I assume that most of the instance data updates will still be done
> using the normal paths that we already handle.  Using mutation events will slow
> us down a little bit on every form.  So then we'd be slowing down everyone for
> the benefit of the few users of forms that use JS to change instance data.
> 
> So I'd say if you change instance data using JS, then you've got to suffer the
> consequences :-)  And if they are smart about it and lump multiple changes
> together before calling rrr, then the tradeoff won't be as bad, either.
> 
> Of course I'll go with whatever the group decides.
> 

I'm agree it's not good to slow down xforms. But in any way I like mutation events here, it's fine feature for xforms in applications. Probably we can provide this by request? Probably additional js method call?

But I guess mutation events issue and issue that you file this bug for are different. Probably for mutation events we should have separate bug?

Comment 6

[aaronr]

(In reply to comment #5)
> (In reply to comment #4)
> > Mutation events would be more efficient in this scenario, but my personal
> > feeling is that the number of forms that change instance values using script
> > will be a very small percentage of the forms that we'll encounter.  And even on
> > those forms, I assume that most of the instance data updates will still be done
> > using the normal paths that we already handle.  Using mutation events will slow
> > us down a little bit on every form.  So then we'd be slowing down everyone for
> > the benefit of the few users of forms that use JS to change instance data.
> > 
> > So I'd say if you change instance data using JS, then you've got to suffer the
> > consequences :-)  And if they are smart about it and lump multiple changes
> > together before calling rrr, then the tradeoff won't be as bad, either.
> > 
> > Of course I'll go with whatever the group decides.
> > 
> 
> I'm agree it's not good to slow down xforms. But in any way I like mutation
> events here, it's fine feature for xforms in applications. Probably we can
> provide this by request? Probably additional js method call?
> 
> But I guess mutation events issue and issue that you file this bug for are
> different. Probably for mutation events we should have separate bug?
> 

I guess I've never really thought of xforms and mutation events together other than how the MDG would use them.  Do you have a scenario in mind where a form author wants to use them?

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)

> I guess I've never really thought of xforms and mutation events together other
> than how the MDG would use them.  Do you have a scenario in mind where a form
> author wants to use them?
> 

I don't understand good what does mean "MDG would use them". Therefore I'll try to call examples where live js modifying of instance document can be useful.

1) XF for app can use the model "model/view/data". Here "model" is template of instance document (some predefined structure of xml file), "view" is couple of xforms controls to show "model" and "data" is instance document once filled by user and posted to server and can be loaded again. Firstly, "model" and "view" are loaded and then if "data" is presented then it should be loaded and merged with "model". As far as I know xforms don't allow to load and merge instance document therefore it should be done from js.

2) Sometimes instance document should contain some application/local machine/user specific data, i.e. the data is not entered by user. For example, if application is client based on xul/xforms for database work then instance document can contain database username for whom application is running.

Comment 8

[alexander :surkov (:asurkov)]

I have one more usecase. Let assume we write application for doctors that gets results of medicine investigation from certain device. In some cases doctor should modify these results and save it. Let assume we save these results as xml file and here it's great to use xforms since after that results from device was added into instance document by js then the rest work will be done by xfroms.

Comment 9

[Allan Beaufour]

(In reply to comment #4)
> Mutation events would be more efficient in this scenario, but my personal
> feeling is that the number of forms that change instance values using script
> will be a very small percentage of the forms that we'll encounter.  And even on
> those forms, I assume that most of the instance data updates will still be done
> using the normal paths that we already handle.  Using mutation events will slow
> us down a little bit on every form.  So then we'd be slowing down everyone for
> the benefit of the few users of forms that use JS to change instance data.

Fair point.

> So I'd say if you change instance data using JS, then you've got to suffer the
> consequences :-)  And if they are smart about it and lump multiple changes
> together before calling rrr, then the tradeoff won't be as bad, either.

But we would only need to listen for changes done through JS, if that is possible?

But, I'll not oppose anything, the recalculate() function should do a full recalculate, so running through all nodes for a script, is ok I guess. I just think that mutation events would be cleaner. Or modifying things through XForms interfaces (but if both are possible, people can choose :) ).

Comment 10

[aaronr]

(In reply to comment #9)
> (In reply to comment #4)

> > So I'd say if you change instance data using JS, then you've got to suffer the
> > consequences :-)  And if they are smart about it and lump multiple changes
> > together before calling rrr, then the tradeoff won't be as bad, either.
> 
> But we would only need to listen for changes done through JS, if that is
> possible?

I don't know much about mutation events other than the concept, and from what I know you can't make this fine of a distinction.  Maybe smaug has a suggestion?

> 
> But, I'll not oppose anything, the recalculate() function should do a full
> recalculate, so running through all nodes for a script, is ok I guess. I just
> think that mutation events would be cleaner. Or modifying things through XForms
> interfaces (but if both are possible, people can choose :) ).
> 

Well, if we supply both, we'll still have to provide the full recalculate when recalculate() is called.  So we should do that under this bug and any new interfaces under another bug where we can figure out what they should look like.  Maybe something that takes an xpath expression, a context node and a value?  We've already got setValue for setting the value of a control by hand via .js.  That will go through the internal recalculate so that is already ok.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms