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

Hi Erik,

Most of my response to this email appears in my response to Nick's earlier 
post.  Here I would add the following:

Let's look again at the sensibility of attaching the MIP attributes to the 
UI control as a decoration on the control, rather than as a convenience 
for attaching MIPs to the underlying data. 

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. 

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. 

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.

Anyway, your point is well-taken about forms being easier to author by 
putting the MIPs on the controls if they are used to *imply* MIP bindings 
on data associated with the controls.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
02/01/2008 01:58 PM

To
public-forms <public-forms@w3.org>
cc

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







I agree with Nick, but I see even more reasons to do this beyond lazy 
authoring and implicit models/instances.

I think that in general, it is counter-intuitive (and a pain) to 
*always* have to create special instances and binds just for the sake 
of specifying things as simple as relevance, read-onliness, or types. 
Many of us resort to creating separate instances just to hold MIPs for 
triggers or to define relevance, for example. This does not bring 
particularly clear benefits, but it certainly does make writing forms 
much heavier than it could be. This realization of course 100% in line 
with the 1.2 goal to make form authoring easier.

As a form author, and whether I have models and instances or not, I 
wonder why I can't just write (I know we have a hack to work around 
this [1]):

   <xforms:trigger relevant="/my/foo = bar">

I also want to be able things like:

   <xforms:input type="xs:date" readonly="/my/foo = bar">

and especially the following:

   <xforms:input ref="/foobar" relevant="instance('type') = 
'input'">...</xforms:input>
   <xforms:textarea ref="/foobar" relevant="instance('type') = 
'textarea'">...</xforms:textarea>

In other words, specifying properties independently from the node to 
which the control is bound.

I know we have a desire to map this to models/instances/MIPs, and 
there are talks about mapping UI properties to MIPs. But I think that 
this is not the right approach. With the current state of things, MIPs 
are somehow communicated to controls upon refresh. We should keep this 
unidirectional and have local properties defined in the UI be combined 
with MIPs at the control level, without otherwise impacting instance 
data.

The alternative doesn't seem to work as it prevents controls bound to 
the same instance data to specify different properties without 
impacting each other, preventing my last example above to work.

It also seems to me that it will be very confusing to think in terms 
of implicit binds to implicit data within implicit instances within 
implicit models ;-) I say we should pick the simplest architecture 
that does the job.

My bottom line: I think we should leave MIPs (as in *model* item 
properties) as they are and add UI-only properties, which are defined 
to be local to controls. We should not bother trying to map these UI 
properties back to binds.

-Erik

[1] Note that the hack we all use, i.e.:

   <xforms:trigger ref=".[/my/foo = bar]">

is a neat one, but newcomers to XForms do find it difficult because 
you have to explain that 1) controls not bound to nodes are non- 
relevant and 2) the XPath syntax to achieve this. I think this does 
remains a hack and should be replaced by a clearer notation.

On Feb 1, 2008, at 5:47 AM, Nick_Van_den_Bleeken@inventivegroup.com 
wrote:

>
> As most of you know there are two main reasons why I (and I hope, 
> we) want to allow model item properties on form controls :
>
>    1. For the easy of authoring when creating simple forms and you 
> are using an implicit instance. When you created your form using 
> lazy creation but want to add some model item properties (for 
> example types, constraints, ...) it would be nice that you just 
> could add those model item properties to the form controls without 
> the need to create a model element nor a bind element.
>    2. When you have a separate model and form UI designer there are 
> cases where the UI designer can add extra model item properties to 
> certain controls that don't need to be enforced by the model (for 
> example extra constraint, stricter type, UI control is read only)
>
> Both these use cases could be solved by creating an implicit model 
> with implicit binds. Treating them as implicit binds will allow a 
> smooth transition when the need arises for explicit binds (e.g.: 
> bind the id-type to all attributes with name id, ...), we can then 
> just merge the implicit and explicit binds, the question about if it 
> is allowed and what happens when the same MIP is specified multiple 
> times for the same node, should be treated separately I think 
> because the same problem can arise when only using explicit binds[1].
>
> I can write up some spec ready text for this but I think it would be 
> better to talk about at the f2f and see if people agree with those 
> implicit binds and that the same MIP specified multiple times on the 
> same data node is another feature (this feature may be a requirement 
> to solve use case 2).
>
> Regards,
>
> Nick Van den Bleeken  -  Research & Development Manager
> Inventive Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Nick_Van_den_Bleeken@inventivegroup.com
>
> [1] : 
http://www.w3.org/MarkUp/Forms/wiki/Same_model_item_property_on_the_same_node

> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
>

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