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: Thu, 07 Jun 2007 11:09:07 -0700
Message-ID: <466849C3.9000904@orbeon.com>
To: public-forms@w3.org

Joern & all,

 >> So the bottom line is that I am not very happy with this
 >> solution. I think we could do one of four things:
 > i completely agree with you both in analysis and your feelings about
 > the 'solution'. Actually i only proposed it in this form in order to
 > not get into too much trouble with current event system.

That's understood ;-)

 >> 2. Use this solution temporarily, but then it's harder to "undo" it
 >>    in XForms 1.2.
 > Agree again. Might be better to really address the problem now than
 > to bend the architecture into place

I agree. I think we all want 1.1 to get out of the door ASAP. But the
issue with UI events, which is made very clear by the instance
replacement scenario, has been bothering me for a long time, and if
there is anything we can do to fix it now, I would be happy to push
1.1 a little further. This is an area where I would be willing to
dedicate some resources (although I would need the famous 48-hour day,
but don't we all).

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

 > But how would that look like? After an instance replace do we fire a
 > xforms-refresh or not? So we would have effectively two kinds of
 > xforms-refreshes - one firing xforms-value-changed events and one
 > firing xforms-control-bound events?
 > Though i thought about an event myself i not at all sure that it
 > makes sense to add a 'xforms-control-bound' event. Where are the use
 > cases here from an authors perspective? If the event only happens
 > after instance replacement couldn't the author not simply use
 > xforms-submit-done then as a hook?

Well, John said that he didn't like the idea of using
xforms-value-changed to signal that a control is bound to a new
node. So I proposed a new event to do just that, rather than having no
event at all dispatched in such case.

If you don't have any events dipatched at all, then listeners for
events on controls are missing an important part of what's going on.

The way it could work is that when new nodes are inserted into an
instance (e.g. with xforms:insert or instance replacement), then all
such nodes are marked for dispatching xforms-control-bound. This makes
sense because the nodes being new, no control can yet be bound to
them. And if a control gets bound to one such node during UI binding
re-evalution in refresh, then the control gets, of course, bound to a
new node, in which case it makes sense that it dispatches the fact
that it is bound to a new node ;-)

Then during refresh, controls bound to nodes marked for dispatching
that event just dispatch that event. The marking/dispatching mechanism
would be exactly the same as the one used for value changes and MIP
events, and dispatching would take place during refresh, like for all
those events.

xforms-control-bound can also be distpached in other circumstances,
such as a control being re-bound to a different node during refresh,
or during UI initialization.

The benefits of this solution are that:

* You don't use xforms-value-changed, which in the current spec
   wording should only be dispatched when node values change. Creating
   new nodes doesn't qualify for node value change, and I think John
   has a good point here.

* You still provide the form author with a mechanism to listen for
   important events (provided we also dispatch MIP events after
   dispatching xforms-control-bound).

The drawbacks are:

* We are introducing a new event. I think such an event would make
   sense and be useful in general, so this is not much of an issue to
   me. If you remove xforms-value-changed on controls becoming
   relevant, then I have a good use case for introducing

* This is just a "patch" to the current system:

   * This doesn't fix the fact that xform-value-changed doesn't do what
     I think it should do, i.e. reliably notify event listeners on a
     control that the value of the control has changed.

   * If you are interested in listening for changes during instance
     replacement, you have now to listen to xforms-control-bound, which
     will be dispatched to every single control bound to nodes in the
     replaced instance. This can have negative performance
     implications. While you may in some cases actually want to know
     that controls are bound to new nodes, I think that in most cases
     listening to xforms-control-bound will just be a workaround for
     the lact of a correct xforms-value-changed event dispatched upon
     instance replacement.

Although I don't want to necessarily advocate this new event solution,
I did want to detail it a little bit more so that people can make up
their mind.


Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Thursday, 7 June 2007 18:22:11 UTC

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