W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: Architectural Consistency Requirements for Forms

From: David Hyatt <hyatt@apple.com>
Date: Thu, 3 May 2007 17:21:42 -0700
Message-Id: <D3A5EA89-F525-4808-AECA-8B5FB6F3A654@apple.com>
Cc: HTML WG <public-html@w3.org>, public-forms@w3.org, Maciej Stachowiak <mjs@apple.com>
To: John Boyer <boyerj@ca.ibm.com>
Here is a link to a bunch of documents describing XUL templates.   
Note that the model back end that XUL templates use is RDF, and I am  
not advocating that at all.  Imagine the feature reformulated to  
operate on an XML DOM back end instead of an RDF graph.

I think there is overlap here too with the <datagrid>.  There should  
be architectural consistency in how it binds to a model and functions  
with that model and any more generic feature that also wants to bind  
to a model.

http://www.mozilla.org/docs/xul/xulnotes/template-primer.html

dave
(hyatt@apple.com)

On May 3, 2007, at 5:01 PM, David Hyatt wrote:

> John, I strongly agree with you.
>
> I don't like the repetition model in WF2 at all, and personally  
> think the whole feature needs to be revisited from scratch.
>
> I would make the following assertions:
>
> (1) A repetition model for generation of tree views, tables, lists,  
> menus, etc. should not even necessarily be bound to a form, so I  
> think a repetition template model should be a language-level  
> feature that is capable of working outside of a form.
>
> (2) A repetition model is (fundamentally) about generating  
> *presentational* markup from some model.  We have this feature in  
> XUL, and the model is held completely separate from the template  
> that describes the presentational markup to use.
>
> (3) It should be possible to bind your template to a model DOM, and  
> an XML model DOM should be supported (including namespaces).
>
> (4) The presentational content should update as changes are made to  
> the back end model DOM, thus allowing you to simply remove an item  
> from the model to have all presentational markup cleanly update.   
> XUL templates work this way, and it's very powerful.
>
> (5) It should be possible to do reasonably complex queries on the  
> model DOM in order to bind to different template patterns.
>
> For example, bookmarks in Firefox can appear in a tree view, or in  
> the menu, in toolbar buttons, etc.  In order to "delete" a  
> bookmark, all you have to do is edit the *model*, and then all of  
> the presentational markup regenerates on the fly.  Different markup  
> is generated for folders vs. leaves, or based off what type of  
> bookmark you might be.
>
> This to me is the killer feature of templates.  Note that there  
> could be additional features if you happen to be inside a form, but  
> I see no reason to tie such a feature to forms at all.
>
> In my opinion, a template system that can't bind to a model DOM,  
> that can't use some form of query language to examine the model DOM  
> declaratively from the template, and that can't auto-reflect  
> changes made to that model DOM is not worth inclusion in HTML5.
>
> dave
> (hyatt@apple.com)
>
> On May 3, 2007, at 4:22 PM, John Boyer wrote:
>
>>
>> I think perhaps the most important bit missing from my off-the- 
>> cuff laundry list is a requirement that I have gotten so used to  
>> taking for granted that it just didn't float to the top yesterday.
>>
>> It's important because it seems to be a bit at odds with some of  
>> the technical approach taken in WF2, which in turn occurred to  
>> optimize a seamingly competitive need.
>>
>> Frankly, it's expressed in our current charter (http://www.w3.org/ 
>> 2007/03/forms-charter.html) in the following sentence:  "It is a  
>> goal that this work will be conducted in a task force jointly with  
>> the HTML WG, draw on the Web Forms 2 work (which moves from the  
>> Web Application Formats Working Group to the HTML Working Group)  
>> and be integrated into the XForms architecture (following design  
>> principles such as the separation of presentation from content)."
>>
>> The key is the parenthetic: a foundational tenet of XForms  
>> architecture is the separation of presentation from content.  
>> XForms has tended to optimize on this tenet.  Part of WF2 reflects  
>> a desire to relax that tenet, and in a number of ways the forms  
>> working group has expressed amenability to that desire.
>>
>> WF2 on the other hand seems to optimize on backwards  
>> compatibility, which no one is arguing against in principle, but  
>> it seems in some places to be carried to the extreme of avoiding  
>> the use of better tags/attributes even for net new features for  
>> which only limited compatibility with html4 browsers can ever be  
>> hoped for.
>>
>> A concrete difference can be seen, for example, with the approach  
>> to repeating structures.  In XForms a <repeat> expresses the  
>> template, and the *data* associated with that repeat determines  
>> how many instances of the template become available at run-time.   
>> In WF2 (http://www.whatwg.org/specs/web-forms/current-work/ 
>> #repeatExample), it is shown that the UI controls are repeated in  
>> the markup itself as there is *no* separation of data and  
>> presentation.
>>
>> 1) Observe first off that the template row is not differentiated  
>> from the data rows, so a poor user experience results when a user  
>> deletes the template row since it is no longer possible to add a  
>> new empty row.
>>
>> 2) Moreover, if all the rows are deleted, then how does the table  
>> ever become non-empty again?
>>
>> 3) And if "mid-population" data is obtained by an ajax call, you  
>> have again the problem of not having an empty row template to work  
>> with.
>>
>> 4) It's also unclear how you'd easily do some kinds of common UI  
>> constructs like adding a new row relative to where the current  
>> focus is located in the table or deleting a row with a button that  
>> is not in the table row.  Maybe these are solvable with current  
>> WF2, but they are common enough use cases to warrant looking at  
>> the markup.
>>
>> 5) Finally, the note at the end of nested repeats about the need  
>> for unicode hacks to bandage the XML non-validity problems seems  
>> another symptom of the need for a better solution..
>>
>> What would be better is a technical approach that allows the  
>> repeating construct to be identified and the template to be  
>> specified, but prepopulation data should be provided through a  
>> separate instance.  It also illustrates what we mean by "scale up  
>> to XForms architecture" while also preserving the most backwards  
>> compatibility with html4 that could reasonably be expected.  Here  
>> is sample of the serialization of the planets and moons example  
>> from WF2 the way it might look with a good separation of  
>> presentation and data:
>>
>> Presentation:
>>
>> <ol>
>>    <li>
>>       <repeat name="planets">
>>          <label for="name">Planet: </label> <input  
>> name="planet" .../>
>>          <h3>Moons</h3>
>>          <ul>
>>             <repeat name="moons">
>>               <li> <input name="moon" /> <button  
>> type="delete">Delete moon</button></li>
>>             </repeat>
>>          </ul>
>>          <button type="insert" repeat="moons">Add moon</button>
>>       </repeat>
>>       <button type="delete">Delete planet</button>
>>    </li>
>> </ol>
>> <button type="insert" repeat="planets">Add planet</button>
>>
>> The data model, which is optional if you don't want to prepopulate  
>> the table, would look like this:
>>
>> <form>
>>   <instance>
>>     <data>
>>       <planets>
>>         <planet>Mars</planet>
>>         <moons>
>>            <moon>Phobos</moon>
>>            <moon>Deimos</moon>
>>         </moons>
>>       </planets>
>>       <planets>
>>         <planet>Neptune</planet>
>>         <moons>
>>            <moon>Triton</moon>
>>            <moon>Nereid</moon>
>>            ...
>>         </moons>
>>       </planets>
>>     </data>
>>   </instance>
>>
>>   <ol> ... from above ... </ol>
>> </form>
>>
>>
>> The html4 browser sees an empty table and some buttons, which  
>> don't work.  This is expected since html4 browsers won't really  
>> understand how to operate html5 repeats, so this is about the best  
>> that can be expected for "backwards compatibility".
>>
>> But an html5 browser now has the desired nested table, and at the  
>> same time all the problems I listed above go away.  The template  
>> is clearly distinct from the data, so you can't delete the  
>> template and you can recover from the empty table problem.  It is  
>> easy to extend the buttons to handle insert/delete at currently  
>> focused location because the repeats are clearly identified for  
>> what they are and don't do double duty as template and data.  And  
>> the above never resorts to XML invalid content, so it is easy to  
>> provide "two equal serializations", one XML and the other tag  
>> soup, that mean the same thing.
>>
>> The benefits don't stop there.  Aside from the runt-ime (i.e. the  
>> concerns of web browser makers), the above separation advantages  
>> not only design tools that seek to make it easier to author forms,  
>> but most importantly the authors of and the CPUs that have to run  
>> server-side code for processing these forms.  For example, it is  
>> much easier to write form prepopulation code (e.g. a JSP) that  
>> just gets some data and drops it in one place in the form than it  
>> is to write the code that has to generate the UI controls to  
>> represent that data.  Aside from being easier to write, the code  
>> is less brittle.  And then there's the tremendously important  
>> aspect of the lower server load that the separation provides.  The  
>> transactional volumes required in government to citizen forms  
>> applications are really critical to consider here.
>>
>> I could continue on about the impact of this separation on other  
>> language features, but this should be enough to exemplify what I  
>> see as being better "architectural alignment" and to substantiate  
>> why it must be done.
>>
>> John M. Boyer, Ph.D.
>> STSM: 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
>>
>>
>>
>>
>> Maciej Stachowiak <mjs@apple.com>
>> Sent by: public-html-request@w3.org
>> 05/03/2007 10:51 AM
>>
>> To
>> Maciej Stachowiak <mjs@apple.com>
>> cc
>> HTML WG <public-html@w3.org>
>> Subject
>> Re: Architectural Consistency Requirements for Forms
>>
>>
>>
>>
>>
>>
>>
>> On May 3, 2007, at 9:13 AM, Maciej Stachowiak wrote:
>>
>> > John mentioned that these thoughts were off the cuff, and he may
>> > have forgotten some important points. I would appreciate it if
>> > XForms experts
>>
>> Oops, I forgot to finish my sentence. "I would appreciate it if
>> XForms experts would mention any requirements they think should be
>> added to this list."
>>
>> Regards,
>> Maciej
>>
>>
>>
>
Received on Friday, 4 May 2007 00:21:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:44 UTC