- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Sun, 3 Feb 2008 23:15:02 -0800
- To: "public-forms (new)" <public-forms@w3.org>
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