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/

Received on Friday, 1 February 2008 18:59:04 UTC