Re: Architectural Consistency Requirements for Forms

Hi John,

On 5/3/07, John Boyer <boyerj@ca.ibm.com> wrote:

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

This is not accurate. The template cannot be deleted by invoking the
repetition behavior (see working "planet" example <
http://weston.ruter.net/projects/repetition-model/testsuite/003.html>). The
template row is differentiated from the data rows in that its repetitionType
DOM property is set to REPETITION_TEMPLATE (versus REPETITION_BLOCK for the
blocks), and furthermore in that the template node does not appear in the
repetitionBlocks NodeSet.

> 2) Moreover, if all the rows are deleted, then how does the table ever
> become non-empty again?

Again, only the repetition blocks are deleted; the template remains intact.
The table becomes non-empty by invoking the template's addRepetitionBlock
method.

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

I agree. I think there should be two more buttons defined for the WF2
repetition model: add-before and add-after. When these buttons are placed
within an instantiated template (a block) then they would insert a new block
in the appropriate location (before and after, respectively). This
functionality, however, can be scripted currently by passing a refNode
argument to the addRepetitionBlock method.

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

I agree. Although perhaps HTML5 should explicitly allow left and right
square brackets in IDs since it's not XML anyway? :-)

Weston


On 5/3/07, John Boyer <boyerj@ca.ibm.com> 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
>
>
>
>