Re: The form tag

Hi Erik,

First, thanks (for the initial comment :-]).

Regarding, the form element implying an initial model that is inside the 
form element, this is exactly what I mean.

The form element wraps the set of things that constitute the implied 
model.  You can esp. see this is true from comments I made about how one 
might provide handlers for events targeted at that implied model.  Simply 
observe them on the containing form element.

My comments about "nested" models refers to what should happen when the 
form author decides to *express* one or more models *within* the form tag. 
 How should those models behave with respect to the implied model?  Well, 
I believe that the authors intent is to have those models work together 
with the implied model, so I believe they must behave as "nested" 
submodels of the implied model that is "nested" within the form tag.

One reason a form author might want to do this is to "mash up" some 
business rules that are defined in multiple places.  So, I think in tandem 
with the notion of nested models, we will find model @src t be 
unavoidable.  With this, it would be easy to define a bucket of 
functionality like the instance data, binds, submissions and/or actions 
needed to talk to some web service.  Once would consume this content with 
a model/@src (or by embedding the model in the form tag), and then one 
could just listen for the xforms-submit-done bubbling up to that model and 
use it to copy data to the master model (the implied model).

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
04/25/2008 06:44 PM

To
"Forms WG (new)" <public-forms@w3.org>
cc

Subject
Re: The form tag







John,

Good thinking.

However, couldn't the <form> element imply a <model> element *nested* 
within a plain <form> element? This way, <form> would always contain 
models and UI controls. No need for nested models here. E.g.:

<form ... attributes for implied model ...>
   <input .../>
</form>

would imply:

<form ... NO attributes for explicit model ...>
   <model>
     ...
   </model>
   <input .../>
</form>

This avoids the awkward situation where <model> contains UI controls.

<form> would then become a full XForms citizen for grouping models and 
controls. It could also be used as well to attach event handlers for 
events which bubble from models as well as UI controls.

Just really quick thoughts.

-Erik

On Apr 25, 2008, at 5:54 PM, John Boyer wrote:

>
> To keep up the discussion between telecons and hopefully get closure 
> sooner, here is a further attempt to explain why we need it for 
> XForms 1.2.
>
> The stream-lined syntax for web authors allows form authors to write 
> UI controls only, with attributes for the things that would normally 
> constitute a model.
>
> Then, they are able to incrementally add other elements that might 
> normally appear in a model, on an as-needed basis.
>
> The form tag would provide a convenient scoping element for logical 
> MVC units.  The model element cannot be used because it surrounds 
> model content, not UI.  The group element cannot be used because it 
> surrounds UI controls, not model content.
>
> But just as we have needed group for scoping of UI, and we have 
> needed model for containment of instances, binds and submission, we 
> now need an element that provides scoping for the whole bundle now 
> that it can be expressed without easily separable markup.
>
> The form tag could:
>
> 1) Consolidate all the internal UI controls and scope them to a 
> single implied model distinct from models associated with other UI 
> controls on the page.
> 2) Serve as a convenient site for observing processing model events 
> for the implied model.
> 3) Provide a web author friendly means of creating a default 
> submission for the data implied by the UI controls
> 4) Allow incremental adoption of other model elements by scoping the 
> elements to the form tag content
>
> Finally, assuming one can live with this view of things, the 
> question arise what to do when the author expresses a model element 
> within a form tag.  This is where it becomes clear that an expressed 
> model can simply be a nested submodel of the model implied by the 
> form tag.
>
> 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
>

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