Re: regarding Action 2007-05-23.2: Value changes upon instance replacement

Hmm... based on today's telecon, I guess I am starting to see the bigger 
picture now, and I am no longer clear on why we need xforms-value-changed 
and related MIP events to be fired in the case of instance replacement.

An instance replacement essentially binds an existing control to a new 
node.

How is that different from having a UI control bind to a new node by 
virtue of a dynamic predicate in the UI binding?

And how is that different from creating a UI control in the first place?

It was a bit of a mistake to say that UI controls which change to relevant 
should receive events for xforms-value-changed and the MIP events.  I 
think this was done with the mindset that you should be able to completely 
control a UI control's appearance using events coming from the model, but 
that is mistaken,  There are times when the control simply has to know 
that it needs to get its updated state from the model.

A change to being relevant should be one of those cases. 

Initial UI creation is one of those cases.

Binding to a new node is one of those cases.

Binding to a node in a replaced instance is one of those cases.

I think it would be better to correct the form control relevance case, 
i.e. say that when a form control changes to relevant, it reflects the 
current state of the model for the node to which it is bound and that it 
does so without eventing.

Then, more clearly state in xforms-refresh that UI controls that bind to 
new nodes due to rewiring or due to instance replacement must reflect the 
state of the newly bound node.

It is problematic to issue xforms-value-changed for a newly replaced 
instance node because that node did not change.  The current 
interpretation of xfomrs-value-changed and the MIP events is that they are 
events dispatched about the data. 

As a future feature, it seems like we are hitting the fact that we need 
better UI level events, and that some serious thought needs to go into 
what that's going to look like.  The current approach is just a piecemeal 
recognition that this is what is happening to us.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Joern Turner <joern.turner@dreamlab.net> 
Sent by: public-forms-request@w3.org
06/06/2007 04:14 AM

To
public-forms@w3.org
cc

Subject
regarding Action 2007-05-23.2: Value changes upon instance replacement







Dear group,

after investigation i found that most of the issue has already been
answered by John Boyer in:
http://lists.w3.org/Archives/Public/public-forms/2007May/0081.html

I fully agree with his John's position. His arguments which i summarize
here shortly for reference:

- MIP events are fired during refresh. Refresh does not happen during
init as controls are *created* (not updated/refreshed) and get to their
state directly without the need for the MIP events. So init and instance
replacement are two different cases which should be kept separate (my
conclusion)

- after a successful instance replacement a refresh (which in
turn will trigger the MIP events) will happen as stated under "11.2 The
xforms-submit Event":

"Once the XML instance data has been successfully replaced, the rebuild,
recalculate, revalidate and refresh operations are performed on the
model, without dispatching events to invoke those four operations. "

In conseguence the problem boils down to the description of the
xforms-refresh Event as John already pointed out.


Proposed new text:

4.3.4 The xforms-refresh Event

(...)
2. A node can be changed by confirmed user input to a form control, by
xforms-recalculate (section 4.3.6), by the setvalue (section 10.1.9)
action or by instance replacement (section 11.18). If an instance data 
node was changed or has been replaced, then the node must be marked for 
dispatching the xforms-value-changed event.

Explanation:
First sentence now mentions the instance replacement as a explicit 
source for value changes. In the second sentence i've deleted 'the value 
of' - i think it's not necessary to talk about the *value* of a node 
here cause a change to the value is of course also a change to the node 
itself.

Though the semantics of xforms-value-changed is not a perfect match 
because of the 'value' in it i do not see another easy solution without 
reworking other parts of the Spec or maybe even inventing a new 
'xforms-instance-replaced' event.

We can even argue that the value of a node has changed even in case it's 
an equally named node with an identical value. The node would not have 
the same identity and so its value as John already pointed out:

"Note that this should occur whether or
not the literal value has changed because the node containing the value
has changed, i.e. it is a different string even if it contains the same
lexical value."

Joern