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

Joern & all:

A very interesting thread.

 > But if i read correctly he also stated that he don't like to use
 > events for the updating at all. And i tend to agree that the
 > instance replacement is a kind of 'internal requirement' to keep the
 > processor in a consistent state.

Oh we agree, again I don't intend these events to be used for updating
the UI. In fact I really don't care how the XForms engine updates its
controls. You are right to say that is an internal requirement, a
housekeeping task. We may use events for that, but it is really not
very important to me.

Again, what I am interested in is notification events that the form
*author* can use, *not* the XForms engine implementor.

 > As i mentioned earlier i don't see the use case for the
 > control-bound event from an authors' perspective. if i'm interested
 > in knowing when a instance replacement has happened i can attach
 > myself to the xforms-submit-done event.

There is a misunderstanding here. The goal is *not* to be informed not
that an entire instance has been replaced, but that a *value* of a
particular control has changed. You would use this with something like
this:

<xf:input ref="item-number">
   <xf:action ev:event="xforms-value-changed">
     ...

In addition, XForms 1.1 introduces a new attribute, @target, on
xforms:submission, which allows replacing on *part* of an
instance. This means that you can't always know for sure what controls
will be affected by an instance replacement: it may just be one
control, or none at all.

 > I don't like the idea too much to introduce a new event for the
 > instance replacement problem cause i'm worried about the performance
 > implications when replacing a big instance. Further specifying that
 > event would potentially prevent implementors from more efficient
 > update solutions.

I agree with this, but note that this has exactly the same problem
that the solution you proposed, and which we implement, which
consisted in using xforms-value-changed.

 > we're currently working on an improvement to the refresh processing
 > that does not require iterating the UI but only touch the controls
 > that really need updating. That solution re-uses the information we
 > already got through the dependency tracking and allows big speedups
 > especially when it comes to big forms.

This is great, and we have been thinking about working on this type of
optimizations as well ;-)

But in general I agree with you: the spec should not propose a
solution, or algorithm, which we know is inefficient, because it then
prevents implementors to do something better.

This seems to rule out us specifying that all nodes are marked for
dispatching xforms-value-changed or the hypothetical
xforms-control-bound event.

But I point out again that what we are trying to resolve here with
events is creating a consistent set of UI notification events. This
is, in my opinion, 100% orthogonal to the internal mechanisms by which
the XForms engine updates the controls.

 > but don't we have the xforms-insert event here? What does the
 > xforms-control-bound event adds for an author? If we can name a
 > clear use case that's not possible with the existing events, then ok
 > i would agree to add it. Otherwise we should stick to Occam's Razor
 > and keep it out. Maybe i'm just lacking imagination here.

I agree with Occam ;-) One situation where the new event could have
been useful was as a notification when a control who was not bound to
a node suddently becomes relevant. John did not like dispatching
xforms-value-changed in that case, so I proposed
xforms-control-bound. xforms-insert is not dispatched in this case of
course, because that is used only when xforms:insert completes.

 > yep, agree that it's semantically problematic to use the
 > xforms-value-changed for the instance replacement and creation of
 > nodes.  We seem to have consensus here.

Good :-)

 > why do you think that current definition of xforms-value-changed is
 > not reliable? Sorry for the dump question but i still do not get the
 > point here.

Well, the whole system is awfully broken, because it is not defined in
terms of control values changing, but of instance nodes changing. This
causes a series of problems due to the loose coupling between controls
and instances. I am trying to cover a few of those below.

Problems with current UI events
-------------------------------

(Note that what follows has nothing to do with using the hypothetical
xforms-control-bound event discused earlier.)

1. xforms-value-changed sent when control value has not changed

    Some element and value in an instance:

      <item-number>42</item-number>

    Control:

      <xf:input ref="item-number">
        <xf:label>Item #</xf:label>
        <xf:action ev:event="xforms-value-changed">
           ...

    Trigger with event handler:

      <xf:trigger>
        <xf:label>Play with instance</xf:label>
        <xf:action ev:event="DOMActivate">
          <xf:setvalue ref="item-number" value="101"/>
          <xf:setvalue ref="item-number" value="42"/>
        <xf:action>
      </xf:trigger>

    When the DOMActivate event handler runs, the instance value goes
    from 42 to 101 to 42 again. From the user's perspective, the input
    control goes from value 42 to, well, 42 again. So in fact it hasn't
    changed between the two UI refreshes. However, the event handler on
    xforms-value-changed will be called as per the spec.

    If you purpose was to detect that the value of the control has
    changed, then you are getting an extra event.

    I know I know, by some funny definition of "value changed", this
    works, but I can tell you that this is never what any of our users
    has been expecting, and we agree with them.

    If you want to detect that the instance node has changed, you could
    use DOM mutation events. But we have never had this use case in
    years of using XForms, while we have the use case of detecting that
    a control value changes all the time.

2. Control value changed but xforms-value-changed is not dispatched

    Some elements and values in an instance:

      <item-number>42</item-number>
      <item-number>101</item-number>
      <item-position>1</item-position>

    Control:

      <xf:input ref="item-number[position() = ../item-position]">
        <xf:label>Item #</xf:label>
        <xf:action ev:event="xforms-value-changed">
           ...

    Trigger with event handler:

      <xf:trigger>
        <xf:label>Play with instance</xf:label>
        <xf:setvalue ev:event="DOMActivate" ref="item-position" value="2"/>
      </xf:trigger>

    After the DOMActivate event handlers completes, the UI refreshes as
    per the spec. The input control's dynamic binding re-evaluates. It
    now points to the second <item-number> element.

    From the user's perspective, the input control has gone from value
    42 to value 101. But the xforms-value-changed handler is never
    called, because the second <item-number> node was never marked for
    dispatching xforms-value-changed, as per the spec.

3. No UI events dispatched upon instance replacement

    Some element and value in an instance:

      <item-number>42</item-number>

      <xf:input ref="item-number">
        <xf:label>Item #</xf:label>
        <xf:action ev:event="xforms-value-changed">
           ...

    The instance containing <item-number> is replaced with the following:

      <item-number>101</item-number>

    The xforms-value-changed handler never runs even though, from the
    user's perspective, the value of the controls goes from 42 to 101.

    This is the initial problem we have been trying to solve in this
    thread.

4. No UI events dispatched upon xforms:delete / xforms:insert

    Same scenario as #3 above, but use xforms:delete / xforms:insert to
    remove the <item-number> element, then insert a new one containing
    a new value.

Ok, I think that this is good for a start ;-)

Note that exactly the same applies to xforms-required /
xforms-optional, xforms-valid / xforms-invalid, and xforms-readonly /
xforms-readwrite.

With the above, I hope to have demonstrated that xforms-value-changed
and other MIP events are broken.

The worst part is that we defined a *complex* system to get here, with
a node-marking algorithm, and specifying which actions and submissions
impact those flags. Fixing problems #1 to #4 above will only make the
specification more complex if we go down the current path.

What Orbeon is advocating is that we get rid of this system and switch
to a very simple system, which specifies that UI events are dispatched
upon refresh when control values and "MIPs" have actually
changed. This is a switch from instance node-centric UI events to
control-centric UI events. Because we are talking about UI
notification events, we think that this makes sense.

This would:

* Provide consistent behavior
* Be easier to understand by both implementors and form authors
* Cover more use cases while being simpler to specify and implement

(And again, not that this proposal does *not* involve the hypothetical
xforms-control-bound event discussed earlier.)

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Tuesday, 12 June 2007 17:47:20 UTC