Re: Add model item properties to UI level (Action 2008-01-23.2)

On Feb 2, 2008, at 7:33 AM, John Boyer wrote:

> As you saw in my note to Nick, readonly on input does not make sense
> because that's an output, and wanting an output to look like a  
> readonly
> input is a styling issue, not an XForms abstract UI issue.

This is not correct at all. An input control can *change* read- 
onliness over time. The approach you describe obviously does not work  
in that kind of situation because it would require that a control  
switch from being an input to an output and vice-versa. And even in  
the unlikely event that we made something like this possible (and  
really we would not!), this wouldn't be good either because the read- 
only input must keep an appearance that identifies it as an input, not  
an output, to the user, even though input is temporarily disabled for  
that control.

I think that it is a common user interface pattern to have input  
fields that switch from read-write to read-only and back over time so  
I guess I don't need to argue about that point.

So we really have an *input* control which happens to be displayed as  
read-only at some point because it has a property specifying that it  
is read-only. This is true whether you use a MIP or a UI property  
(UIP?).

I have even a better argument coming:

When we (strongly) argued about whether the read-only MIP should  
actually protect the XForms model's data from any external  
modifications, back at the Madrid f2f, I proposed a use case where the  
data in the model should be modifiable with <setvalue/>, but an input  
control bound to data had in fact to be read-only. This is a use case  
that makes sense if at a certain point, data entry is not possible by  
the user, but the instance data can change in the background, for  
example as a result of a series of actions or an instance replacement.

With the new semantics of the read-only MIP, this is hard to do: you  
have to somehow disable that MIP to change a value. This is one reason  
I was against the strong read-only MIP proposal, and I lost. BUT, IIRC  
it was suggested at that point that having the ability to have a read- 
only property on the control would be a solution to this problem.

Clearly, if the read-only property on the control creates an implicit  
bind, my use case is still not satisfied. While if it is just a UI  
property, then it is.

> Similarly, it makes no sense to attach relevant to a particular  
> control;
> if you want to hide a particular control, you can use the XPath  
> predicate
> trick in the UI binding, or more appropriately, style it to  
> display:none
> or visibility:off.  Again, per control properties like this look like
> styling to me, and should not be confused with MIP attributes.

I think that this conclusion is reached too fast.

Styling a control this way with CSS doesn't work: if you always want  
the control to be visible or hidden, sure, do that. But the reason I  
want to use XPath to control relevance is because that relevance can  
change over time.

And as I have said, the XPath trick is just that, a trick, and one I  
think we should move away from as fast as we can.

So we still end up with a non satisfactory solution to independently  
control the relevance of individual controls bound to a same node.

So I can only object to the first two arguments made above.

> Attaching constraint to a particular control and not meaning for it  
> to be
> applicable to the underlying data makes even less sense.  If you do  
> have
> two controls bound to the same data node, but you only attach the
> constraint to one control, then if you add bad data in the other  
> control,
> you are guaranteed to show invalidity in the control bearing the extra
> constraint.  What kind of user experience is that?
>
> For required, it similarly makes no sense to have one UI control  
> requiring
> data entry and another not requiring it for the same node of data.   
> The
> only way it makes sense is if you plan to sometimes hide the control  
> where
> the data is required.  But in that case, you're really setting up a
> *condition* on whether or not the data is required (it's the same
> condition that would show or hide the control that would bear the  
> required
> attribute).  So again, with proper use of the feature, you could still
> attach required MIPs to the controls and actually intend for the  
> attribute
> to be a *model item* property.

I agree that constraints and required properties are problematic. But  
do we *have* to have these two properties directly on controls?

I guess you will answer yes if you start with the a-priori idea that  
what you want to build are implicit binds, mainly for lazy authoring  
purposes.

But if like me you are more interesting in a simplified syntax for  
large forms, and in satisfying the use cases I presented above, then I  
don't think that there is a huge requirement for having these two  
properties directly on controls.

But if they really are needed, there may be some ways out. For example:

* Only those properties that clearly must impact instance data could  
create implicit binds, while read-only and relevant would behave  
differently.
* We could create new names for these two UI properties, and consider  
that they exist in addition to the current MIPs.

-Erik

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

Received on Monday, 4 February 2008 07:15:17 UTC