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

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:
gners.com/email-disclaimer

Received on Thursday, 23 August 2007 15:58:01 UTC