- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Wed, 05 Sep 2007 11:17:58 +0200
- To: public-forms <public-forms@w3.org>
John, Thanks for the clarification on the erratum. I don't agree with some of your comments below, mainly I don't think that as specified, MIP events do a "perfectly good job" for anything useful I can think of. I don't have a strong opinion on whether 1.0 said at some point that MIP event should (or could) be dispatched during initialization. Some WG members think so as you have seen in this thread, but it was certainly not very explicit if it was the case. At any rate, we did not implement that dispatching, and for all practical purposes I would consider this as not mandated in 1.0. Note that there is no technical problem dispatching MIP events at the end of initialization. It's just a matter of picking the right time. Things would be maybe easier if the spec was written in terms of performing an initial refresh of the user interface at the end of initialization. I understand we have a process to follow, but I cringe every time the topic of UI events is tackled because I think that this is broken since the first XForms 1.0 spec. Then some 1.0 errata made that broken behavior even better specified by detailing how refresh must dispatch these events, and that's what we now have in 1.1 as well. Regarding the error summary use case I provided: it is certainly the main use case we have, but even if that use case was not a good one, or even if we provided other ways of implementing it in XForms, I would still argue that the UI events are broken because not reliable. I have thought quite a bit about this, and I am not sure we can make them reliable with the current way UI events are defined, i.e. based on changes to bound nodes rather than changes to the controls. As Nick suggested, maybe then we should just get rid of UI events altogether, if we are not able to fix them. -Erik John Boyer wrote: > > 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/ > > -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Wednesday, 5 September 2007 09:18:11 UTC