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

Hi Ryan,

I don't see why an additional event is needed specific to instance 
replacement.  Why can't the form author just key off of the 
xforms-rebuild?  Afterall, the instance may be completely changed in 
structure by more than just a submission replacing the instance.  Could 
also be due to an insertion at the root node level, by someone using JS 
to change the instance, or a combination of these followed by a xforms 
reset.  Though I guess the problem here is that xforms-rebuild isn't 
always generated.  Like if xf:rebuild or rebuild() is done directly.

So I think that this issue is wider than just instance replacement.

--Aaron

Ryan Puddephatt wrote:
> 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
>

Received on Tuesday, 5 June 2007 17:10:07 UTC