- 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