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

Hello all,

Welcome back John! ;)

With respect to John's hard work, I see the problem here as being the
valiant attempt to clarify the MVC issues in XForms, but unfortunately
in a way that hasn't been fully agreed upon.

Up until the 'big changes' the specs were a little vague as to what
should happen with readonly, relevance and so on, in relation to the
'M' part of MVC. Although not ideal, I'd always felt we could live
with this vagueness, because to be more precise would require a lot of
work to clarify how 'M' should be perceived.

But the changes that John has made recently, seem to reflect one view
of where 'M' should be heading, and understandably some people
disagree with that direction. I know that you can make a case for the
approach John has taken--and he does so, very well--but I feel that
the nature of the vagueness in the prior specs means that you can also
make a case for lots of different interpretations.

So I'm with Mark S on this when he says that his real worry is that
these changes seem to be taking us away from a more encapsulated
approach, without having had the opportunity to debate it.

For this reason I would recommend a return to the status quo ante,
which means living with the vagueness for a little longer, until we
have time to properly debate what exactly we want 'M' to be.

Regards,

Mark

On 05/09/07, Joern Turner <joern.turner@dreamlab.net> wrote:
>
> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Wednesday, 5 September 2007 11:05:10 UTC