Re: Erratum that removed the sending of MIP related events on model-construct

Nick and all,

before actually rolling back this change we should IMO take a closer 
look at the MIP events. It popped up shortly in the discussion on last 
telecon (don't remember who mentioned it) that the overall usefulness of 
MIP events can be questioned.

So first question to me is:
are there people outside using the MIP events for form authoring? Are 
there really use cases for them? Please excuse the dumb question but i 
myself haven't found a single case in the past where i needed these 
events as a form author.

If we can't find striking use cases for MIP events they should be 
deprecated and removed from the Spec for the following reasons:
- reduction of complexity
- reduction of processing overhead. DOM Events are not really a cheap 
thing to process with all their capturing, blubbing and stuff. Every 
value change fires a whole bunch of these which easily leads to hundreds 
of events for reasonable complex forms

Same argument applies for the init phase. I remember not too long ago 
during the telecon it was said that we don't need the initial MIP events 
cause the whole UI is *created* in contrast to being refreshed after 
state changes in the instance. Of course when a control is created it 
already gets its initial and correct state. So i don't see a strict 
reason for firing the MIP events on init from a model-consistency point 
of view.

Further we shouldn't forget that it's not the MIPs causing the UI being 
up-to-date - they are pure notification events. The UI state itself has 
to be updated by the processor itself in an implementation-dependent way 
as current wording says:
4.3.7:
(...)
5. The user interface reflects the state of the model, which means that 
all form controls reflect to their corresponding bound instance data:(...)

This correctly says what a processor is expected to do not how to do it 
and certainly not through the use of MIP events. These a solely reserved 
for the form author.

And finally, if we're finding cases where the author wants the MIP 
events right after init why not just use

<xf:action ev:event="xforms-ready">
   <xf:refresh/>
</xf:action>

Just an implementors opinion: from my point of view i don't like to fire 
the MIP events during or right after init phase. This definitely 
generates all lot of event processing for potentially exotic use cases 
and i prefer a better startup time for the majority of use cases.

Maybe i'm just missing the important use case but it should be an 
important one to justify the overhead.

Regards,

Joern

Nick_Van_den_Bleeken@inventivegroup.com wrote:
> All,
> 
> We were talking on the phone about '4.2 Initialization Events' and this is 
> the erata I meant. It removed the dispatching of the events on 
> xforms-model-construct:
> 
> http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E29a
> 
> Regards,
> 
> Nick Van den Bleeken  -  Research & Development
> Inventive Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Nick_Van_den_Bleeken@inventivegroup.com
> 
> 
> --------------------------------------------------
> 
> Inventive Designers' Email Disclaimer:
> 
> http://www.inventivedesigners.com/email-disclaimer
> 
> 
> 
>

Received on Thursday, 30 August 2007 13:50:23 UTC