- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 30 Aug 2007 21:18:42 +0200
- 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 are: * 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 thread). But this is not enough. I have already shown that MIP events and xforms-value-changed are dispatched unreliably in this message: http://lists.w3.org/Archives/Public/public-forms/2007Jun/0030.html 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 behavior. 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 initialization. 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. -Erik 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 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 >> >> >> >> > > -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Thursday, 30 August 2007 19:18:59 UTC