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

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

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 06 Jun 2007 14:51:20 -0700
Message-ID: <46672C58.4040402@orbeon.com>
To: public-forms@w3.org

Joern & all,

We tackled some of this in today's call, but I wanted for the record
to comment a bit on the solution below for the record.

It is my understanding, based on our discussion in the call, that the
proposed solution comes down to marking every node in the instance as
requiring dispathing xforms-value-changed upon instance replacement.

If that's the case, and if we were to actually require this, I think
we should make it much more explicit and amend the wording in the
submission to state this.

But now about this solution in general:

What Joern describes is, by the way, the solution we implement in Orbeon

However, even though we do implement it this way, we do not think that
it is a great solution. We implemented it because like Joern, we
couldn't find a really better solution given the tight requirements and
the way refresh is currently specified.

Consider the following control:

   <xforms:input ref="some/element">

and then an instance like this:


I can change my instance almost completely to:


Before instance replacement, my input is bound to the unique "element"
node. Then after replacement, upon refresh, the input is newly bound
to an "element" node. However, the structure of the instance has
changed quite a bit. In this case, I have decided not to change string
value of the element, so in both cases the input control will show

The solution to mark all nodes works, but it is costly and
non-optimal. It is also intuitively incorrect in that control whose
value has not changed will all dispatch xforms-value-changed.

We can argue, as John did, that the *element node* has changed, but
remember the name of the event is *value changed*. XForms authors,
including myself, really think that "value changed" should say what
its name implies, i.e. fire when the control value changes.

So the bottom line is that I am not very happy with this solution. I
think we could do one of four things:

1. Wait for XForms 1.2.

2. Use this solution temporarily, but then it's harder to "undo" it in
    XForms 1.2.

3. Introduce the xforms-control-bound event, mark all nodes for
    dispatching it, then dispatch MIP events. What we gain from this is
    that at least we don't incorrectly use the words "value changed".

4. Do more work and implement UI events correctly, that is in a way
    which is less confusing for form authors and which would be
    hopefully 100% reliable, i.e. a control would dispatch
    xforms-value-changed if and only if its value has changed since last


 > 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

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Wednesday, 6 June 2007 21:52:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:52 UTC