Re: MIPs as information, behavior of setvalue/insert/delete/submission/etc for readonly nodes, and the MVC architecture

John, All,

I included my reply in-line.

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 09/05/2007 08:42:51 AM:

> 
> MVC is a well-known architecture, which we have long claimed was the
> basis for XForms. 
> 
> I believe that our version of "model" is a little different that 
> classic MVC because in classic MVC the data model is passive, 
> providing only the data and accessors.  We embellish it with "model 
> item properties" that calculate results and annotate the data with 
> information such as relevance and validity. 
> 
> But it has *always* been clear that (despite _some_ confusion over 
> the exact definition of form control) that the "view layer" is 
> defined by the core form controls, and the containers, and 
> specifically that XForms "actions" are not part of the view layer 
> because they do not provide a view.  They have a different kind of 
> binding.  It is a foreign idea that I cannot use the term 
> "controller" to describe them; MVC is, in my opinion, well-known 
> enough and calling it out as an ill-defined term is rather like 
> saying "iteration" and "loop" and "exception" are not properly 
> defined in our spec. 
> 
> You can call them whatever you like, but in the MVC architecture, 
> actions live in the controller piece, not the model piece.  The fact
> that you can put XForms actions INTO the model is mere syntax sugar 
> offered by XML events.  Suppose, for example, that we excluded 
> XForms actions from the content model of XForms model.  One can 
> still hook the events targeted at a model, its instances and its 
> submission from the outside by simply using more XML events 
> attributes.  Being inside the content of a model element is 
> meaningless for deciding whether actions are "part of the model or 
> the controller". The key issue is whether the thing performs an 
> imperative change or change sequence in response to an event. 
> That's a controller in MVC parlance.  You can have a controller that
> modifies the model, or it can modify the view.  For example, you can
> write an xforms-ready handler *inside* the model and have it toggle 
> a switch in the view layer.  Would you say that the toggle is part 
> of the model when clearly it is controlling an aspect of the view 
> layer?  Of course not.

I completely agree with your view about what model, view and controller 
are (it is in sync what I previously said in the 'Big update to XForms 1.1 
spec; Ready for your review' thread). 
 
> 
> The fact that XForms actions are part of the controller  means they 
> are not part of the model, but also (as stated above) that they are 
> not part of the view layer either, even if the actions appear within
> view layer content.  This is part of why I do not believe that the 
> use of ref in setvalue implies, in any way, that setvalue consumes 
> any model item properties, and most notably not readonly.

A setvalue action doesn't needs to consume any model item properties. The 
model enforces the read-only property. In programming language 'slang' the 
API that the model provides, to allow the setvalue action update a node, 
should enforce the read-only behavior.
 
> 
> A similar issue arises with setvalue and relevant.  Should a 
> setvalue not occur on a non-relevant node?  The spec makes no 
> connection between setvalue and these MIPs and it makes no effort to
> claim that setvalue is a form control, so the answer should be yes, 
> setvalue can change a non-relevant node.

I can't find any language in the spec that let me believe that 
non-relevant nodes aren't available to the controller. I find a lot of 
references that those nodes should not be available to the UI (e.g.: The 
relevant model item property provides hints to the XForms __user 
interface__ regarding visibility, focus, and navigation order., in 9.1 The 
XForms Group Module,... ) and that they should be pruned by submission.
 
> 
> Even better examples occur in actions like insert/delete DO NOT even
> have a ref.  They have a nodeset, and our spec makes no effort to 
> connect insert/delete and the readonly MIP.  Moreover, non-relevant 
> nodes certainly are not removed from a nodeset before it is consumed
> by insert/delete (that would break a lot of forms out there). 
> Again, none of these elements are targets of xforms-readonly/xforms-
> readwrite, nor xforms-enabled/disabled because these MIPs just don't 
apply.

Here I want to use the same argument as with the setvalue action. It is 
the model that will enforce this.
 
> 
> The XForms submission uses ref, yet it can do instance replacement 
> into readonly content, and it gets even better at doing so in XForms 
1.1. 
>

In XForms 1.0 you can not replace a part of your instance, the ref is used 
to select the subtree that is submitted, and if it points to a 
non-relevant node, an submit-error will occur because there is nothing to 
submit because all none relevant nodes are pruned. So as you can only 
replace the whole instance there is no relation with the read-only MIP

In XForms 1.1 you can use 'target' to only replace a subtree of an 
instance. But due to the text in 6.1.2 The read-only property '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 submission will fail to replace the subtree if the target-node is 
read-only.
 
> An XForms calculate can, by definition, modify a read-only node! 

Agreed but as pointed out in the 'Big update to XForms 1.1 spec; Ready for 
your review' thread, those are both MIPs and word together.

> 
> And perhaps the most damaging problem for XForms is that it exposes 
> a DOM interface (for those who implement a DOM) that provides direct
> and unrestricted access to the underlying data.  If the intention 
> had been to have the model enforce properties like read-only, then a 
> much tighter interface would have been required here because one can
> use the DOM interface *provided by the XForms processor* to change 
> nodes that are read-only *according to the XForms processor.* 

It is well known that there are problems with providing full access to the 
DOM to the outside. But if you read the spec it states in 7.3.1 The 
getInstanceDocument() Method 'returns a DOM Document that corresponds to 
the instance data associated with ...' there is no language that says that 
it is the same DOM object instance that the implementation internally uses 
(if it uses DOM internally in the first place). So you can read this as if 
the XForms processor should return a DOM Document (is just an interface) 
that maps to the internal DOM document and that any changes on the 
returned DOM Document should be mimicked on the internal instance 
representations if the operations aren't prohibited by the model. I know 
that until now no implementations has implemented it like this, but I 
don't see why the current wording implies what how I read this now. (I 
know maybe this a bit of a stretch, and maybe we should drop this method 
and add other more specific methods to the model, on the other hand fixing 
a small issue in the spec, in a section that is considered not good, by 
breaking other well defined sections is a stretch too)

> 
> This is just an overwhelming body of evidence to prove that it was 
> the statement in Chapter 6 that was not as carefully written.  I 
> hate to invoke Occam's Razor, but gosh this situation just begs for 
> it.  The readonly MIP *should* make it impossible for *an end-user* 
> to directly change a data node *using a form control*.  But a 
> "programmatic" change coming from the controller layer or the model 
> is so clearly allowed in most cases, and there should be no 
> piecemeal exceptions made based on not knowing all the other ways a 
> readonly node can be changed during XForms processing. 

I hope my arguments will provide a basis for a good discussion about the 
change that was made regarding the read-only MIP.

> 
> John M. Boyer, Ph.D.
> STSM: Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com 
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer



--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer

Received on Wednesday, 5 September 2007 09:42:09 UTC