Re: Architectural Consistency Requirements for Forms

Hi Dave,

On 5/3/07, David Hyatt <hyatt@apple.com> wrote:

> (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.
....
> 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.

The WF2 repetition model is not bound to forms, even though it appears with
in the "Web Forms" specification. Templates may be made of any elements by
adding the relevant attribute (repeat="template") and so the WF2 repetition
templates work "outside of a form." In order to declaratively make use of
the repetition model's functionality, however, one must use the new WF2
repetition model form buttons. Perhaps this is what you are referring to.

Weston


On 5/3/07, David Hyatt <hyatt@apple.com> 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
>
>
>
>
>