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

Mark & all,

I responded to Nick's original message earlier. A few more comments
below:

> I agree with Nick, the proposed change to read-only should not be
> undertaken lightly, and I would prefer it not to be undertaken at
> all.

Whether it is an change or not is debatable, unless we know the
original intents of whoever designed the readonly MIP. Apparently, not
all the consequences were thought out, as I tried to explain in my
other message.

> Surely if a model author (as opposed to form author - they may not
> be one and the same) wants to specify the conditions under which a
> node is read-only, they will simply want the node to be
> read-only. They might not even know what class of application will
> bind to the model - there may never be a form involved.
>
> If a form author finds that there are circumstances under which they
> need to prevent a user from changing the value of a node that
> according to the model is actually writable, then that is an
> entirely different matter, and it is a shortcoming of XForms that
> there is no convenient way to achieve this other than by messing
> directly with the model. As Nick says, XForms needs its own UI
> centric method for disabling form controls bound to particular nodes
> (or perhaps just disabling particular controls - you may have
> several controls bound to the same node and want to just disable one
> or other of them in particular circumstances).

I don't really disagree with the fact that "read-only" may mean two
different things. I have myself argued that the definition of "empty",
for example, was pretty useless from a user's perspective, and it was
countered to me that it made sense from a programmer's perspective. My
conclusion is that maybe we need two types of "empty" (wrt the
required MIP).

Certainly, the form user is usually not the form author. The form
author is a crazy guy (generally) working all day long in a very dark
room. The form user is a normal person.

But as much as we would like to imagine people writing models and
other people writing UI's using those models, I have yet to see that
division of work really happen. This reminds me very much of such
divisions, very much theoretical, established in specifications such
as JavaServer Faces. It's as if five different people could work on a
user interface at the same time. I am not saying this never happens,
but I have yet to see it. I personally have only had use cases where I
wanted to prevent the *user* to change values, but not my own
*actions*. This may purely stem from the fact that we at Orbeon
usually write both models and UI. I would expect this situation to be
very common based on what I have seen from our users and customers.

It would be nice to protect a form author from his own mistakes, but
then we have to think about the cost of it, at least the cost of
implementing it properly.

> And another thing. Why should read-only be any different to
> calculate, or type? Are we saying that some MIPs only relate to the
> UI?

I am not sure I understand this question. But from an eventing
perspective, we do dispatch all MIP-related events to the UI, not to
the model. That's probably because they are actually much more useful
in the UI.

> I suppose I don't really see the model as belonging to XForms any
> more than it belongs to any other XML vocabulary. The model is a
> useful construct that allows me to define sets of related data
> structures and their relationship as a unit to the outside world. It
> actually makes me uncomfortable every time I have to add any UI
> centric code to a model. Or is that just my itchy underwear?

> I guess what I really want is a model that is my data model, that
> doesn't know or care what consumes it, just so long as it is
> consumed on its own terms (all MIPs honoured, thank you very much),
> and a separate, form model that provides the local context. There I
> can play merrily with all my UI toys, safe in the knowledge that the
> data model to which my form binds is looking after its own thing.

> So, if the XForms model is the XForms model, it needs more UI
> centric functionality and by-the-way, can someone please invent this
> other "back-plane-model-thingie" that we need;
>
> or
>
> if the XForms model is the "back-plane-model-thingie", can we please
> invent another, UI centric model for use with forms?

I know there have been lots of talks about the backplane and all. But
for me, XForms is a tool to define, well, forms, and so far, the
XForms model is part of XForms, and I think that we should strive to
make XForms a great forms solution before anything else. Just my own
opinion (well, Orbeon's opinion).

The XForms model, while a model in an MVC architecture, remains, for
me, the model for a user interface. I am sure we can imagine other
useful uses for it, and we should probably make it as independent from
the UI as we can reasonably do so, but I fail to see a great future
for the backplane. Heck, we better make sure that XForms has a great
future, and there is a whole lot to do still to make that happen.

This opinion is partly motivated by the fact that, as a working group,
we have only limited manpower, and I would much prefer seeing all WG
members work on making XForms a great forms solution rather than
dissipating energies in multiple directions at a time.

> I don't mind which way round it happens, but it would be great to
> have clarity and consistency, so we all know what we mean by "the
> XForms model" :-)

What about "a data model for a forms-based user interface" ;-)

-Erik

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

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