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

Hi Erik,

Seems like a lot of your response is really also getting at the fact that 
we have a separate feature that needs to be worked out.

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.
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).

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. 

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
06/06/2007 02:17 PM
Please respond to
ebruchez@orbeon.com


To
public-forms@w3.org
cc

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







John & all,

 > Hmm... based on today's telecon, I guess I am starting to see the
 > bigger picture now, and I am no longer clear on why we need
 > xforms-value-changed and related MIP events to be fired in the case
 > of instance replacement.
 >
 > An instance replacement essentially binds an existing control to a
 > new node.
 >
 > How is that different from having a UI control bind to a new node by
 > virtue of a dynamic predicate in the UI binding?
 >
 > And how is that different from creating a UI control in the first
 > place?

The first two are very similar, yes, but the last one is different, as
I note further below!

 > It was a bit of a mistake to say that UI controls which change to
 > relevant should receive events for xforms-value-changed and the MIP
 > events.  I think this was done with the mindset that you should be
 > able to completely control a UI control's appearance using events
 > coming from the model, but that is mistaken, There are times when
 > the control simply has to know that it needs to get its updated
 > state from the model.

I think I see better what the big issue is here: we have to figure out
why xforms-value-changed (and other MIP events, but let's focus on
value changes for now) is a useful event at all.

There are two main uses of events in general as I see it:

1. As a tool for form authors, so they can figure out things happening
    in the form.

2. As a cute tool for XForms spec authors and XForms implementors,
    which allows expressing parts of the internal XForms engine's
    behavior in terms of events.

#2 is a nice thing to have. But I think we, as the forms working
group, have to make an effort to focus on user-centric features. This
includes understanding that events are primarily introduced to satisfy
form authors use cases, i.e. #1 above.

We at Orbeon don't care that much that controls update their values by
receiving xforms-value-changed or by some internal magic. That's an
implementation detail. If in the working group we find that events are
the best way to do it, that's great. If not, that's not a big deal.

But what we care about is that form authors have the means of using
events to be informed about changes in the form.

This is incidently why at the Amsterdam f2f last year we decided to
dispatch xforms-value-changed and other MIP events when controls
become relevant again: so that a form author placing an event listener
on that control can know reliably that the value of the control has
changed, and/or that some MIPs have changed (in fact, *may* have
changed - you have cases where you are informed and nothing has
changed, but at least you have no case where things change and you are
not informed).

 > A change to being relevant should be one of those cases.
 >
 > Initial UI creation is one of those cases.
 >
 > Binding to a new node is one of those cases.
 >
 > Binding to a node in a replaced instance is one of those cases.

I am not sure I agree with the above. Yes, initial UI creation is
similar to a control becoming relevant after being non-relevant. But
that's where the comparison stops in my opinion. A control being bound
to another node was relevant and is still relevant, unless the
relevant MIP changes between the nodes. Same in case of instance
replacement.

 > I think it would be better to correct the form control relevance
 > case, i.e. say that when a form control changes to relevant, it
 > reflects the current state of the model for the node to which it is
 > bound and that it does so without eventing.

This would be a real issue because then there is no way to listen to a
control and be reliably informed of changes in the control's value or
validity, among others. So at the moment I can't agree with this if
that's all there is to it.

A possible solution could be to introduce a new event:

   xforms-control-bound

This would be dispatched whenever a control is bound to a new node,
including:

1. Initial UI creation.
2. Change in the result of a dynamic UI binding.
3. Instance replacement.
4. New nodes inserted with xforms:insert.

Then I would argue that xforms-control-bound should also be followed
with the MIP events, so that an event listener can reliably know about
the validity of a newly bound node.

I am just suggesting this as a way of reconciling John's proposal with
the simple requirement of being able to use xforms-value-changed and
other MIP events to be informed when something changes. I came up with
this new event idea in a few minutes, so it may or may not be a good
idea.

As I have said several times in the past, it all comes down to making
these events useful. If you can't rely on them at all, then you could
as well take them all out from the spec and our task for 1.1 would be
much easier.

 > Then, more clearly state in xforms-refresh that UI controls that
 > bind to new nodes due to rewiring or due to instance replacement
 > must reflect the state of the newly bound node.

This would be a reasonable consequence. Add to that nodes changed with
xforms:insert/xforms:delete.

 > It is problematic to issue xforms-value-changed for a newly replaced
 > instance node because that node did not change.  The current
 > interpretation of xfomrs-value-changed and the MIP events is that
 > they are events dispatched about the data.

Well, there are different types of nodes:

* Element nodes containing text nodes, to which controls read and write.
* Attribute nodes.

Upon instance replacement, the element node changes. Upon setvalue,
the text node changes. I don't think it is obvious what we mean when
we say that "a node changes" ;-)

 > As a future feature, it seems like we are hitting the fact that we
 > need better UI level events, and that some serious thought needs to
 > go into what that's going to look like.  The current approach is
 > just a piecemeal recognition that this is what is happening to us.

I agree.

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.

It's not that we can't find some explanations for the current
system. But for somebody new to XForms, it is very confusing that
xforms-value-changed, while dispatched to the control, doesn't
actually regard the value of the control but the value of nodes, and
that the control my change bindings all the time.

I think the right way to do this event is to say that a control must
remembers its previous value between refreshes (if it changes at all),
and then upon refresh "somebody" (it could be the control itself)
determines whether the control must be dispatched xforms-value-changed
if its value has actually changed. Then the context info for the event
can even contain the old AND the new value.

"Change" can be specified with equality. We touched a bit on this
durint the call today: to me, it can be pure lexical equality and I
think we would have something perfectly acceptable.

My opinion is that the system of "flags" in instance data nodes is
quite a sub-optimal solution, which keeps raising all sorts of issues,
and it is very non-intuitive to the form author.

-Erik

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