- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 30 Aug 2007 18:51:07 +0200
- To: public-forms <public-forms@w3.org>
Sounds good to me. At least we got a few arguments down and while time-consuming that is a good thing. I really hope to be able to make it to Madrid on Thursday and Friday. Let's make sure this makes it to the agenda. -Erik Nick_Van_den_Bleeken@inventivegroup.com wrote: > Erik, and the rest that is following the discussion, > > Isn't it better that we postpone the discussion to the next f2f meeting in > Madrid there we can communicate synchronous (whith no deferred update ;) ) > And then it will be hopefully easier to a common resolution. What do you > think about that? > > Regards, > > Nick Van den Bleeken - Research & Development > Inventive Designers > Phone: +32 - 3 - 8210170 > Fax: +32 - 3 - 8210171 > Email: Nick_Van_den_Bleeken@inventivegroup.com > > public-forms-request@w3.org wrote on 08/30/2007 03:48:28 PM: > >> > Quote from our abstract defining what our XForms model realy is : a >> > declarative model composed of formulae for data calculations and >> > constraints, data type and other property declarations, and data >> > submission parameters [1] >> > >> > It also clearly defines what the XForms view and controller are : - >> > a __view__ layer composed of intent-based user interface controls - >> > an imperative __controller__ for orchestrating data manipulations, >> > interactions between the model and view layers, and data >> > submissions. >> > >> > As I read this, this clearly states that event handlers/actions are >> > part of the controller not the model. (It may even support that the >> > message action is part of the view.) >> >> I will point out that this is the brand new abstract John wrote for >> 1.1. The word "controller" appears only there in 1.1, and it did not >> appear at all in 1.0. >> >> I think that I reacted to this abstract positively when feedback was >> asked, but I now realize that the spec needs to define better what the >> model, view and controller are, if we are to mention them at all. I am >> not sure there was a debate in the WG about this. When you say that >> XForms events and actions are part of the controller, to me that's >> just a guess based on John's abstract, and again, I am not sure there >> was any debate around this. >> >> For me the controller, if there was one, was something rather external >> to XForms constructs: it was the part of the software that implements >> the processing model defined in XForms and that glues everything >> together. I did not see this as concretely as to include XForms events >> and actions. >> >> In a past discussion, I argued that sequences of XForms actions >> followed an imperative model. IIRC, Mark Birbeck argued back that this >> was not right, and that you could see even XForms actions as being >> quite declarative. I did not agree with that, and I may be >> misrepresenting Mark's opinion, but this hints to me that not >> everybody agrees that "XForms actions" = "imperative code" = >> "controller". >> >> At any rate, I think we need to precise all this, and I remain >> unconvinced that event handlers and actions declared in the model >> should not be considered as "part" of the model. >> >> > Section 10 XForms Actions[2] defines the concepts 'outermost action >> > handler', inner action handler' and 'Deferred Updates'. If we no >> > longer believe in the defered effect of XForms action on the XForms >> > model (transactional effect), we should carefully investigate what >> > the side effects are and write text that deals with all the picky >> > details. But this discussion should be held in the context of a >> > feature version(I'm not sure if we want to change this behavior, >> > since it was already well defined in XForms 1.0 first edition), not >> > a change in a spec that is in post-last call state. >> >> I don't think the above correctly reflects the intent of the mechanism >> of deferred updates. >> >> First, IMO the purpose of the system of deferred updates is to allow >> to realistically implement XForms without suffering exagerated >> performance issues. If bindings could be instantly evaluated all the >> time at zero performance cost, I don't think we would need this >> complex system. This just seems necessary for performance reasons so I >> am fine with it. >> >> Second, you have to look at the impact of the deferred update >> mechanism wrt MIPs. Before the UI refreshes, we make sure that >> recalculation and revalidation has occurred. This is crucial for the >> consistency of the user interface, as the author has the expectation >> that the UI will be in sync with the model. So whether we perform the >> updates in a deferred way or not, this has little consequence for the >> UI: the user will see a control as read-only or with an alert >> consistently with the state of the model, every time a refresh >> occurs. >> >> When we do refreshes has consequences for UI events dispatching, but >> that seems unavoidable as we have to pick a moment where UI events are >> dispatched. In this sense, I would argue that the "transaction" (and >> this probably not the best term as we don't support commits and >> rollbacks) contains whatever occurs between two UI refreshes. >> >> But enough about refresh. Look at what happens before a submission >> occur: we make sure that MIP synchronization happens. This is because >> the author has a natural expectation that the constraints he has set >> are valid at the time of submission. The whole WG seemed to agree that >> it was bad that you could actually, in certain circumstances, submit an >> instance with out of sync relevant MIPs. >> >> In my view, this is exactly what should happen for xforms:setvalue, >> xforms:insert, and xforms:repeat if we say that they must honor the >> MIP. >> >> I know that three members have said that this was clearly a feature of >> 1.0, but given that the initial spec authors do not seem to have >> carefully looked at the consequences of it, I raise some doubts about >> this statement. If the text for xforms:setvalue clearly said in 1.0 >> that it must honor the readonly MIP, I would not be able to argue >> against this point. But at the moment, to me, this seems more like a >> half-baked feature rather than a well thought-out one. >> >> I guess that the debate continues ;-) >> >> -Erik >> >> -- >> Orbeon Forms - Web Forms for the Enterprise Done the Right Way >> http://www.orbeon.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 16:51:31 UTC