- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 4 Sep 2007 20:57:17 -0700
- To: ebruchez@orbeon.com
- Cc: public-forms <public-forms@w3.org>
- Message-ID: <OFF375B19D.050EED3E-ON8825734D.0011A05E-8825734D.0015BDE5@ca.ibm.com>
Hi Erik (and Nick and Joern and all), Yikes! A big error has been made here. Erratum E29a (cited by Nick at the beginning of this thread) did *not* remove the sending of MIP related events on model-construct. There has been absolutely *no* change to XForms; the MIP-related events have never been dispatched on initialization, nor on instance replacement. All E29a said was that xforms-rebuild, recalculate and revalidate would happen as behaviors rather than events (so that they are not cancellable during model construction). This has *nothing* to do with sending MIP related events on model-construct and in fact there are categorically *no* changes to XForms 1.0. There is even a note in XForms 1.0 first edition in xforms-revalidate clarifying that "xforms-valid and other MIP-related events are not dispatched during the xforms-revalidate that happens during model construction). It is good to know that there are additional use cases where it would sometimes be useful to have them all the time. However, XForms 1.1 is way past last call, and we will easily blow our charter schedule if we were to take on more scope now. I am quite concerned about asking the W3C for more time on XForms 1.1 given that it has been three years in the making and that we are discussing an issue that has *always* been a part of XForms. To me, the point of XForms 1.2 and XForms 2.0 is to continue addressing new and emerging use cases as working group members begin to feel the motivation to address them. It is particularly important to take this approach when the new use cases conflict with the pre-existing use cases that caused the earlier versions of the language to have certain properties. In the particular case of MIP-related events, they are not dispatched on initialization because we did not want a poor user experience esp. in the case of xforms-valid and xforms-invalid if the form author actually attempts to capture the event and present information to the user, e.g. a message. So, I think it is unfair to say that the spec mandates "broken" behavior. It doesn't mandate behavior that supports the feature you want, which is a form-wide error round-up. It does a perfectly good job of letting a form author present an ephemeral message when the node the control is bound to *becomes* invalid as the result of XForms processing *in the current session*. As a discussion about XForms 1.2/2.0, the use case of an error round-up is interesting, but we really need to have a look at it in terms of markup to decide whether the *feature* should even be done via eventing. It seems you need eventing and more context info AND the context info you described isn't enough in the case of repeat... Maybe a more direct construct is needed, like some kind of action that can query the current user interface and generate the error list into a node. Don't get me wrong; I get the use case and in fact we have people who are doing it right now with our own custom extensions. But we do need to treat this like a feature request. Cheers, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Erik Bruchez <ebruchez@orbeon.com> Sent by: public-forms-request@w3.org 08/30/2007 12:18 PM Please respond to ebruchez@orbeon.com To public-forms <public-forms@w3.org> cc Subject Re: Erratum that removed the sending of MIP related events on model-construct 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 Wednesday, 5 September 2007 03:58:17 UTC