Re: Big update to XForms 1.1 spec; Ready for your review

 > 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/

Received on Thursday, 30 August 2007 13:48:34 UTC