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/

Received on Saturday, 26 April 2008 01:45:17 UTC