W3C home > Mailing lists > Public > public-forms@w3.org > August 2007

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

From: Joern Turner <joern.turner@dreamlab.net>
Date: Fri, 24 Aug 2007 01:12:27 +0200
Message-ID: <46CE145B.2060703@dreamlab.net>
To: Nick_Van_den_Bleeken@inventivegroup.com
CC: ebruchez@orbeon.com, "Forms WG (new)" <public-forms@w3.org>, public-forms-request@w3.org

Hello all,

i think the arguments why readonly (in its current form) relates to the 
model like all other MIPs and that this should not be relaxed in any way 
have all been named by Mark and Nick before so that i don't want to 
stress that point too much again.

Just a few remarks as they have implications for a possible UI-centric 
i've always seen MIPs as part of the Model and nothing else. As alone 
the name 'Model Item Property' says they attach constraints to a XML 
structure. So as Mark and Nick already said the readonly facet has to be 
respected regardless if the value is changed by setvalue, user 
interaction, instance replacement or whatever.

This leads me to the conclusion that a UI-centric readonly can't be 
allowed to contradict the setting in the model cause that would break 
the intend of the model designer. Constraining the model MIPs (and 
Schema constraints) further in the UI would be possible, the other way 
is a serious problem for the integrity of the model IMO.

Though i see the possible usefulness of more fine-grained control on 
control behavior by allowing certain 'locally scoped' attributes to e.g. 
make a readonly control (which btw sure is something completely 
different than to make a *value* readonly). But it seems to me that this 
needs definitely more thinking and should be handled with extreme 
caution to not confuse XForms authors and therefore is something for 
future versions (beyond 1.1) of XForms.

*** off-topic warning ***
In last consequence the whole discussion for me seems to underline the 
wish of many XForms authors to take a more UI-centric approach on XForms 
authoring. The accepted need for something like XForms Transitional 
underlines this thesis.

Being involved with XForms for years i'm lately more and more concerned 
about the complexity XForms grew into. - Though descriptive it's not 
really fun to understand, refactor or extend a complex form that you've 
written weeks ago. Mainly the indirections between controls and binds 
make it a lot harder to see the picture. UI-centric code in contrast can 
be read more or less sequentially.

It's not that i'm promoting to move away from XForms principles 
developed so far (in contrast) but to offer an alternative that ideally 
can co-exist with (or at least be transformed into) XForms FULL and does 
not break with the idea of using a Model.

Other MVC languages can give interesting inspiration on how to design 
this - e.g. Java Swing knows control-level models - each control has 
it's own micro model but manipulates that by using the same interface as 
  the control would use to speak to the frame level model (and 
triggering same events). In XForms speak that would mean that every 
XForms control has its own micro model and communicate with the XForms 
model (if any) in a defined way.

Sorry for interruption - think i needed to say that once ;)



Nick_Van_den_Bleeken@inventivegroup.com wrote:
> Erik & all,
> I included my comments inline
>> Nick & all,
>> A few comments on Nick's issues below:
>>  > 4.4.11 The xforms-readonly Event and 4.4.12 The xforms-readwrite
>>  > Event
>>  > Is group not a valid target for the xforms-readonly and
>>  > xforms-readwrite events?
>> It probably should IMO, if as a rule we adopt that every control with
>> a single-node can be a target for UI events. The same would go for
>> xforms:switch then, but not xforms:repeat, which does not have a
>> single-node binding.
>>  > 6.1.2 The readonly Property
>>  > Previously section 6.1.2 The readonly Property[1] clearly stated
>>  > that "When evaluating to true, this model item property indicates
>>  > that the XForms Processor should not allow any changes to the bound
>>  > instance data node." And I know for certain that Chiba, the Firefox
>>  > extension,… block the setvalue action from changing read-only
>>  > content. I know that it is hard to enforce this if you provide
>>  > direct access to the DOM through script. But I don't think we should
>>  > sacrifice the nice separation in our MVC architecture, the model
>>  > needs to be the one that enforces the read-only property both to the
>>  > View (the UI) and the controller (the actions). I know that the
>>  > previous wording needs some tweaking because it doesn't say if a
>>  > submission is allowed to replace inside read-only content, and if it
>>  > isn't allowed what exception is dispatched. But it clearly states
>>  > that no changes are allowed, we should think twice before changing
>>  > this. It breaks backwards compatibility, is counter intuitive (at
>>  > least for me) and in my personal view breaks the principle that data
>>  > integrity is enforced by the model. If we really want a UI read-only
>>  > attribute it should live in the UI and be an attribute on the form
>>  > control and not on the binding in the model.
>> I am not sure what to think of this, especially since I had never
>> considered that xforms:setvalue should be prevented to change a
>> read-only value. However I understand now, by reading the text more
>> carefully, how Chiba and other implementations have decided to enforce
>> this.
>> This said, if *really* we want xforms:setvalue to honor the readonly
>> MIP, *then* we need to specify that before running, if the recalculate
>> flag is set, a recalculation is performed (and probably if the rebuild
>> flag is set, rebuild should be performed as well before). Otherwise,
>> the number of situations where the readonly property will be out of
>> date will be quite large, and that would make the readonly constraint
>> unreliable.
>> (As a side note, and as I have said before, I don't like this type of
>> unreliability, which gives form authors misplaced confidence, which is
>> why we need to review completely our system of UI events, but that's a
>> digression.)
> I don't see it like that, it is well defined in the spec when 
> recalculations happen and you can see a sequence of actions inside another 
> action as a transaction. This allows for example changes to the newly 
> inserted nodes until the transaction is closed (read the outermost action 
> is terminated). As I heard this has been up for debate numerous times in 
> WG and it has be estabilished what the correct behavior was :
>   - setvalue can't update a read-only element
>   - you can not insert or delete in a read-only node
>   - pre xforms 1.1 submission could replace readonly nodes, because it 
> replaced the instance (not the subtree) so you got a new instance 
> This also resulted in the clear text : "When evaluating to true, this 
> model item property indicates that the XForms Processor should not allow 
> any changes to the bound instance data node." 
> The last point about submission needs be revisted because we can now have 
> the result of a submission to be stored somewhere inside the instance. I 
> personally think that replacement should be allowed if the node that you 
> try to replace isn't read-only, it should be disallowed if the node your 
> try to replace is read-only.
>> On the other hand, my fear is that requiring that xforms:setvalue
>> honor the flags can be extremely costly in long sequences of actions,
>> as each setvalue itself will cause the recalcuate flag to be set. So a
>> long sequence of setvalue will be hashed with recalculations.
>> If existing implementations that implement this behavior do not set
>> the recalculate flag, then IMO they are in error as the readonly MIP
>> will be unreliable.
>> In addition, assume you have a readonly node, say:
>>    <first-name/>
>>    <xforms:bind nodeset="first-name" readonly="true()"/>
>> Now what if you xforms:delete that node: are you allowed to do so?
>> What about deleting a parent element of <first-name/>?
>> What then about inserting a new <first-name/> element? What about
>> instance replacement upon submission, which now allows replacing a
>> subtree and therefore is equivalent to xforms:insert/xforms:delete?
>> What about (ouch) xforms:copy?
>> I am trying to show here that things are not as simple as saying that
>> setvalue just looks at the current readonly MIP before deciding what
>> to do.
>> In addition, I have to say that I have not had personally a practical
>> use case for setvalue to behave this way, so I have a little bias
>> against this functionality.
>> In addition, allowing setvalue to, well, change a read-only value,
>> does not appear to be as heretical as that: the readonly MIP is the
>> only way we have to mark a control as read-only in the UI, and to
>> prevent that control, temporarily or not, to write values to an
>> instance node. This responds to an important use case.
> I personally think that we need the ability to mark a form control as 
> read-only, but this is a new feature and something that is up for 
> discussion in XForms 1.2. You can also have a use case where two inputs 
> bind to the same data node, but one input needs to appear read-only and 
> the other one appearing read-write.
>> On the other hand, a form user cannot perform an xforms:setvalue
>> action. He can only interact with the form through the UI. So in the
>> end, while it would be maybe desirable in certain cases to protect the
>> form author against certain mistakes, the form author has control over
>> his source code anyway.
>> And of course, enforcing this feature, besides the relative complexity
>> and performance implications of a *correct* implementation, also
>> prevents certains use cases.
>> For example, say the form author wants to make a control read-only to
>> present information retrieved from a database with a submission from
>> being changed by a user who does not have the right to change that
>> data: you will use the readonly MIP in that case. But the what if you
>> want to update that data with the result from another submission? You
>> may be prevented to do just that, or you will have to make the code
>> much more complex by creating flags controlling the readonly MIP
>> property, set that flag, modify the value with setvalue, and reset
>> that flag. In the meanwhile, you hope that XForms processing will not
>> allow that temporarily disabled read-only-ness of the associated
>> control to show the control as read-write (this should be ok as this
>> should happen only during a refresh).
> This can be achieved by the 'new' UI read-only attribute.
>> I am sure there are better use cases, but I just wanted to show that
>> in certain situations, as a form author you would like the power to
>> change instance data in the background, while you still want the user
>> not to have write access to that data.
>> All this said, it is important that we consider this topic and discuss
>> it thoroughly.
>> -Erik
>> -- 
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
> Regards,
> Nick Van den Bleeken
> --------------------------------------------------
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
Received on Thursday, 23 August 2007 23:08:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:53 UTC