W3C home > Mailing lists > Public > www-forms@w3.org > June 2007

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

From: Ryan Puddephatt <ryanpudd@googlemail.com>
Date: Tue, 5 Jun 2007 10:54:48 +0100
Message-ID: <ea95792a0706050254i75f66560m57eebeb82dc99eb4@mail.gmail.com>
To: www-forms@w3.org
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.


Received on Tuesday, 5 June 2007 15:24:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:20 UTC