W3C home > Mailing lists > Public > public-forms@w3.org > August 2007

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

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 30 Aug 2007 21:18:42 +0200
Message-ID: <46D71812.8070203@orbeon.com>
To: public-forms <public-forms@w3.org>

Joern & all,

It is right that, *as they are currently defined*, the MIP events are
close to being useless unless an implementor makes some enhancements
that are not mandated by the spec.

One big use case we have is what we call the error summary. I showed
an example at a previous f2f in Amsterdam. This consists in having a
part of the form that summarizes the errors that have happened on the
form, for example at the top of the screen, or wherever the form
author wants to place it.

An XForms implementation could decide to build-in such summaries, but
every form author wants something slightly different. By implementing
MIP events correctly, you give form authors the ability to track this
kind of changes in the UI and easily implement such functionality with
a little snippet of XForms + XHTML and a little corresponding model
(having a system of components in XForms would make this even easier).

So the answer to your first question is: at Orbeon, yes, we have a use
case which we think is very important, and we would like the XForms
spec to support correctly this use case.

The enhancements we have made in Orbeon Forms wrt MIP events so far

* Dispatching them upon initialization. Apparently, other
   implementations (formsPlayer?) do this as well.

* Adding context information to the event such as the control id,
   alert information, etc.

* Implementing dispatching of MIP events upon instance replacement
   (following the same strategy which Joern proposed, and which
   unfortunately is not a good one as we already covered in a separate

But this is not enough. I have already shown that MIP events and
xforms-value-changed are dispatched unreliably in this message:


I don't think I need to re-explain all this, but we at Orbeon don't
think that it is acceptable that the specification mandate such broken

I fully agree with Joern's idea that MIP events are not necessarily
used to update the UI: they are notification events. I say
"necessarily" because there is the possibility that an implementation
could use them to update the UI (but I haven't checked if this is
actually possible).

Your idea of using xforms:refresh upon xforms-ready won't work,
because the nodes' MIP markings are cleared during
initialization. Refresh will occur, but no MIP events will be
dispatched. An alternative is to perform a submission upon
xforms-ready, but I call this a hack.

Regarding the cost of dispatching these events, there is a very easy
solution for Chiba (I assume): you can do what we do in Orbeon Forms
and simply never dispatch a particular UI event if there is no event
listener registered for that UI event. And if there is no UI event
listener at all, then you can skip an even bigger part of the
process. This is a static analysis which can be performed during form

So we both agree that something should be done about UI events, but I
think it would be better to define them correctly rather than
supressing them.

Finally, it would be great to hear of other use cases from other form
authors or implementors.


Joern Turner wrote:
 > 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 
 > 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

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Thursday, 30 August 2007 19:18:59 UTC

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