Re: No value changed initialization and instance replacement fix (continued from telecon minutes)

Hi all,
   I'm new to the W3C Xforms list, but not Xforms, I've been working with
Orbeon Forms for nearly 2 years now. I'm replying to Erik's email on
Instance Replacement.

>2. What to do upon instance replacement
>---------------------------------------
>
>I personally don't read much in there that hints at an interpretation
>supporting node replacement ;-) So I think it come down to what we
>think refresh should do upong instance replacement, and it seems that
>we agree it should do something rather than nothing.
>

I agree in some cases events need to be fired.

>One issue to consider is that refresh is based on nodes having been
>"marked" for change, instead of controls themselves comparing their
>old value with their new value.
>

I agree they should be compared on a node basis, not a control basis.

>Now, during instance replacement, the whole structure of an instance
>can change, and the entire instance can be changed, which means that
>during refresh a control will be bound to a completely new node
>recently created by parsing the document returned by the submission.
>
>A simple but coarse solution would be to mark all nodes of the new
>instance has having changed. This will cause all control bound to
>nodes of the replaced instance to send xforms-value-changed
>events. This is what we do in Orbeon Forms at the moment, pending
>something better.
>

Surely if a node is in the orignal and replaced instance, you would
assume they are the same node. Therefore compare them and only fire
and xforms-value-changed if they differ. It seems a little wrong to
fire a xforms-value-changed when the value might not have changed only
the instance has changed within the application.

>This may not be considered optimal because a control's value may
>actually not change upon instance replacement (i.e. it may point to a
>new node but containing the same value).
>
>On the other hand, this is already possible now in XForms if a control
>changes value multiple times between refreshes: it will be marked for
>xforms-value-changed, even if from the user's point of view the value
>of the control hasn't actually changed between the two UI refreshes.

This is true, but that will be intentionally changed by a
xforms:setvalue, rather than a replacement instance.

What about in the case of a counter,

<xforms:setvalue ev:event="xforms-value-changed" ref="/count" value=". + 1"/>

This would not only be fired when the user changes the node value, but
also when the instance is replace, which could be a save submission,
where only minor changes occur.

>
>Fixing this part would mean drastically changing the way we do
>refresh, and I doubt we would want to do this now.
>
>So is there an alternative now to marking every node for dispatching
>xforms-value-changed during instance replacement?

Perhaps an additional event is need, xforms-node-replacement? If the a
developer needs the xforms-value-changed to be fired as well they can
alway. capture this additional event and dispatch an
xforms-value-changed. At least they then have the choice.

Thanks

Ryan