W3C home > Mailing lists > Public > public-forms@w3.org > May 2007

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

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 29 May 2007 17:56:08 -0700
To: public-forms@w3.org
Message-ID: <OF211D2D99.D22458B6-ONCA2572EB.0003D7F3-882572EB.00052472@ca.ibm.com>
We intentionally do not issue value *changed* and other events on UI 
initialization.

We don't do it when the UI is first created during model construct done 
default processing, and we don't do it when new controls are created in 
response to dynamic changes to the form, such as a repeat generating an 
additional set of controls.

In general, new UI controls are expected to be able to get their values 
and MIP states directly from the XForms processor *without* events being 
fired.

Note that we especially point out in model-construct that no 
xforms-refresh is issued on initialization, and that model-construct-done 
*creates* the UI.  There is no refreshment needed because it just got 
created!

I agree that *something* needs to be done about instance node replacement, 
but I believe this is a minor oversight in xforms-refresh handling that 
should be corrected.

Look carefully at bullet points 1 and 2 in xforms-refresh processing 
(http://www.w3.org/TR/xforms11/#evt-refresh)

I interpret bullet point 1 as being applicable to nodes that have been 
replaced.

I interpret bullet point 2 as being applicable in the case where the UI 
binding points to a different node. 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.  I am open to any wordsmithing the group feels is necessary 
to achieve the effect, but this bullet point is definitely the place to 
fix the instance replacement problem.

Finally note that if a control binding to a new node created by instance 
replacement implies that we consider its value to have changed, then 
bullet point 3 gives us the fact that it will get events for all the MIPs 
too.

This is why I think it is just an oversight in xforms-refresh and not 
something that should cause us to perform a more major surgery on the 
event lifecycle.  For example, dispatching the events on UI initialization 
would mean that alerts for invalid content would fire on startup, which is 
not the intent.

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
Received on Wednesday, 30 May 2007 00:56:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:43 UTC