Re: Architectural Consistency Requirements for Forms

John,
I meant to direct you to this working test case of the "Repeated rows" spec
example which you referred to: <
http://weston.ruter.net/projects/repetition-model/testsuite/002.html>

Weston

On 5/4/07, Weston Ruter <westonruter@gmail.com> wrote:
>
> 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
> >
> >
> >
> >
>