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

Erik Bruchez wrote:
> 
> 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.
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.

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.

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.

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.
> 
> 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.
Well, i mentioned it already - as i see it the updating of controls 
after an instance replacement is a housekeeping task for the processor 
and shouldn't be of interest for the author but i'm open to learn ;)

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


> 
> 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.
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.
> 
> * 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
>   xforms-control-bound.
> 
> * 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.
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.

Joern
> 
>   * 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.
> 
> -Erik
>

Received on Tuesday, 12 June 2007 11:30:04 UTC