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

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.)

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.

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).

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.

 > 9.3.3 Repeat Processing
 > The new text introduces the concept of a 'repeat object'. And says
 > that "The capture and bubble phase of XML Events dispatched to these
 > run-time objects is confined to the repeat object." Does 'confined
 > to the repeat object' mean that the events don't start at the root
 > of the xforms document when the capture phase begins and ends back
 > at the root after the bubble phase?

IMO events should be captured from the root, and bubble back.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Wednesday, 22 August 2007 17:30:40 UTC