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

John & all,

 > There is one part of your response below that veers away from that
 > though.
 >
 >  >xforms-value-changed dispatched to a UI control should just mean
 >  >that the value of the form control has changed! It really
 >  >shouldn't be more complicated than that.
 >
 > The xforms-value-changed is a notification to a control that the
 > data node to which it is bound has changed value.

My comment above just reflects on the fact that, in my opinion, the
way eventing to controls is currently defined is, to put it bluntly,
broken.

As you pointed out, controls are perfectly able to pick up their new
values without events being sent to them. "4.3.4 The xforms-refresh
Event", point 5 does say how a control updates its state:

   "The user interface reflects the state of the model, which means
    that all forms controls reflect for their corresponding bound
    instance data:

     * its current value
     * its validity
     * whether it is required, readonly or relevant."

In short, the control itself doesn't have any use whatsoever for
xforms-value-changed, according to the spec. And I think that this is
perfectly fine.

So if the control doesn't need it, who needs it? The answer is: form
author-specified event listeners on that control.

And what do I expect as a form author from listening to
xforms-value-changed events on a control? That the event be dispatched
to the control when the value of the control changes. The same goes
for MIPs.

I am seriously wondering why, as a form author, you would need to ever
know that the value of the node to which the control is bound has
changed. But if you really wanted this, couldn't you achieve this with
DOM mutation events placed on the instance?

On the other hand, as a form author, I am constantly in need of
knowing that the value of the *control* has changed. And its MIPs as
well.

I am aware that the XForms spec says otherwise at the moment, as you
say, that:

    "The xforms-value-changed is a notification to a control that the
    data node to which it is bound has changed value"

But in my opinion this is just a design flaw, not only because this
yields to the semantics of xforms-value-changed events being hard to
grasp (even for fairly advanced XForms users), but also because of
further negative implications, such as the issues we have seen
recently about what to do upon instance replacement.

Incidently, I think that fixing this design flaw would also make the
spec simpler.

 > It is a separate thing to say that the value of the form control has
 > changed.  This is the problem (that these two things are being
 > thought of as the same).

Agreed, it is. What I am saying is that xforms-value-changed *should*
reflect that the value of the form control has changed since last
refresh, *not* that the node to which the control is bound has changed
value. And the reason I am saying this is because I have only use
cases requiring the former, but no use case requiring the latter.

Maybe some other people have use cases for the latter?

 > As a design flaw, we really don't have machinery that notifies a
 > control to say that the node to which it is bound has changed.  That
 > seems to be the new feature that is needed.

This is one way of going forward, and such a mechanism would be useful
whatever decision we end up making.

But I do wish that we could at some point change the UI eventing
system to make more sense, which to me means be control-centric
instead of instance node-centric.

However, if we keep patching the current eventing system, we may have
a very hard time coming back, and we will end up with just an ugly
mess.

-Erik

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

Received on Thursday, 7 June 2007 00:25:21 UTC