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

Hi Mark and John,

John,

first of all i agree with your description of the MVC in the context of 
XForms. To cut it short:

model = instance + Schema + MIP constraints
view = form controls (XForms UI)
controller = actions

This is straightforward and matches the common interpretation of the MVC 
pattern. I also agree that the location of a certain tag doesn't say 
it's part of one of the above components.

But i do not agree that the controller (actions) should be allowed to 
circumvent constraints defined by the model. In this i tend to follow 
Mark's position.

If we compare the model with other model components commonly found e.g. 
a database model (which can play the model role in a layered 
architecture) you'll never assume that a field in a table can be changed 
by a certain action but not through user interaction when defined as 
readonly.

 From the point of view of the model it should be irrelevant if the 
attempted value change comes from an action or through direct user 
interaction. A model in a MVC (as i understand it) defines the logical 
structure of the data along with it's constraints and is responsible for 
enforcing those. Controller and View should always play nicely *within* 
the bounds set by the model and attempts to break certain constraints 
should be denied. And not to forget that's why the readonly MIP takes an 
XPath - you can change the status of readonly to false() if that makes 
sense within your models context.


I do not quite understand with 'consumes any model item properties' in 
context with e.g. the setvalue action. As i see it the setvalue action 
is directed to the model - it does not need to know about the MIPs. The 
model does and enforces these as it is it's responsibility.

Think i agree with Mark's position - we should rather fix the DOM 
interfaces than allowing actions to mutate the model without enforcing 
readonly.


Mark Seaborne wrote:
> Hi John,
> 
> I hope you had a good vacation :-)
> 
> I guess I see the model as a package of schema + instances, decorated 
> to give it a well defined operating context. I realise that as defined 
> it is not quite there, and perhaps I should just accept that. But it 
> seems a crying shame (to me) to be so close to something so useful, but 
> to be slowly getting further and further from the ideal.
> 
> To me a form control is just a tidy way of writing a set of actions 
> that invites receipt of a value from an external source - possibly, but 
> not necessarily, a human interacting directly with a user agent - 
> although obviously that is the major use case. I don't really see the 
> differentiation you underline between the interaction 'twixt form 
> control and model and 'twixt actions, or other external code and model. 
> It is all just code to me. If I define in my model that under certain 
> conditions anything matching this XPath expression is read-only, then 
> that is just what I mean.
> 
> I agree that one might wish to implement different rules depending on 
> whether an instance is altered one way or another; that can be true 
> whether there are form controls or not. I would argue that just as the 
> model honours the schema, so anything that binds to the model should 
> honour it. However, I have been caught out and disappointed many times 
> when, in my enthusiasm, I have attempted to author forms based on this 
> mistaken presumption.
> 
> I also agree that there is inconsistency in the text we have at the 
> moment, but I would argue for change in the opposite direction. I think 
> we should declare an intent to fix DOM access to instance data so that 
> the model _is_ taken into account. I also think that we should fix 
> XForms actions along the same lines. At the same time we need to make 
> sure an author can simply say such things as "this data, defined by the 
> model as writable is, in the context of my application, read-only to 
> form controls and script, but not to the setvalue action", for example. 
> Obviously not in the time frame of 1.1. :-)
> 
> Maybe we could introduce some mechanism for qualifying MIPs? It would 
> be nice to be able to say explicitly: "This node is read-only to form 
> controls when condition x is true, and read-only to everything when 
> condition y is true" Then we will all be happy :-)
> 
> All the best
> 
> Mark
> 
> 
> 
> 
> 
>         
> 
> 
> 
> 
>

Received on Wednesday, 5 September 2007 09:49:21 UTC