- From: David Hyatt <hyatt@apple.com>
- Date: Thu, 3 May 2007 17:21:42 -0700
- To: John Boyer <boyerj@ca.ibm.com>
- Cc: HTML WG <public-html@w3.org>, public-forms@w3.org, Maciej Stachowiak <mjs@apple.com>
- Message-Id: <D3A5EA89-F525-4808-AECA-8B5FB6F3A654@apple.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:48 UTC