Re: Comparison of XForms-Tiny and WF2

Even XForms Full can be implemented in Ajax/Javascript. See for instance  
http://www.formfaces.com/

Best wishes,

Steven

On Thu, 18 Jan 2007 18:19:47 +0100, Jon Ferraiolo <jferrai@us.ibm.com>  
wrote:

>
> Hi,
> I have a very simple question from the land of Ajax (and OpenAjax
> Alliance). Can either XForms-Tiny or WF2 be implemented in JavaScript  
> such
> they run on today's browsers, or do they both require new version of
> browsers (or plugins) to ship before the features can be used?
>
> Jon
>
> Jon Ferraiolo <jferrai@us.ibm.com>
> Web Architect, Emerging Technologies
> IBM, Menlo Park, CA
> Mobile: +1-650-926-5865
>
>
>
>             Matthew Raymond
>              <mattraymond@eart
>              hlink.net>                                                  
> To
>              Sent by:                  Dave Raggett <dsr@w3.org>
>              public-appformats                                           
> cc
>              -request@w3.org           www-forms@w3.org, WHAT WG List
>                                        <whatwg@whatwg.org>,
>                                        public-appformats@w3.org
>              01/17/2007 07:57                                       
> Subject
>              PM                        Re: Comparison of XForms-Tiny and
>                                        WF2
>
>
>
>
>
> Dave Raggett wrote:
>> Dean Jackson suggested I write up a brief comparison of XForms-Tiny
>> and WebForms 2.0. You can find this on the Forms wiki at:
>>
>>        http://www.w3.org/MarkUp/Forms/wiki/XForms-Tiny
>>
>> WF2 and XForms-Tiny both involve incremental extensions to HTML
>> forms as defined in HTML4 and DOM2 HTML. XForms-Tiny includes a much
>> richer range of features[...]
>
>    Are you referring to HTML Web Forms or WF2?
>
>> [...] that greatly reduce the need for page
>> specific scripting compared with WF2.
>
>    I disagree. The scripting in WF2 that would be needed to support the
> same features as XForms-Tiny (XFT) isn't significant. The benefits of
> XFT are mostly ease-of-use and the fact that native support won't
> require Javascript to be enabled. More on this later.
>
>> This will effect the relative
>> cost of developing form-based applications with the two proposals
>> since Web page scripts are prone to bugs and these are expensive to
>> iron out.
>
>    This is misleading. In most cases, the same functionality in WF2 can
> be replicated by a single line of scripting.
>
>> XForms-Tiny is also much easier when it comes to repeated
>> groups of controls, avoiding WF2's tight coupling to HTML tables.
>
>    There is no such tight coupling with tables. You're using
> non-normative examples as the basis for this conclusion. In reality, the
> WF2 repetition model is far more flexible and has a greater range of
> features. I would point out that your own repetition model appears to
> only support repetition in <fieldset> elements.
>
>> This is important for device independent markup and the experience
>> offered to users on mobile devices.
>
>    Note that <fieldset> repetition is possible with WF2, so your
> argument here isn't valid. Besides, WF2 was implemented on Opera, and
> they're a major distributor of web browsers for small devices.
>
>> WF2's output element also raises challenges for
>> implementation on existing browsers.
>
>    The <output> element is inline, and its contents are strictly for
> fallback. Browsers that don't support it will just render the fallback.
> Aside from a few CSS issues with obvious workarounds, this isn't an  
> issue.
>
>> The rich declarative features of XForms-Tiny lend themselves to
>> exporting the XForms model and constraints for use in server-side
>> data validation. In principle, XForms-Tiny could also be used to
>> submit structured form data as XML, although this has not been
>> implemented as yet.
>
>    How would this compare to the multiple encoding methods available in
> WF2? Specifically, application/x-www-form+xml.
>
>    http://whatwg.org/specs/web-forms/current-work/#form-submission
>
>> I strongly recommend you try out the examples on the XForms-Tiny  
>> testbed:
>>
>>     http://www.w3.org/2006/11/XForms-Tiny/
>>
>> The WebForms 2.0 submission can be found at:
>>
>>     http://www.w3.org/TR/web-forms-2/
>
>    Let's do a comparison using the XFT Testbed.
>
> http://www.w3.org/2006/11/XForms-Tiny/
>
> === Data types, e.g. number and date ====
>
>    WF2 has the types "number" and "date".
>
> === Constraining field values with regular expressions ===
>
>    WF2 supports patterns via the |pattern| attribute.
>
> === Calculated fields using spreadsheet-like formulas ===
>
>    Here is the element that calculates a value in the testbed example:
>
> | <input id="f3" name="sum" calculate="x+y" datatype="number"
> | readonly="readonly"/>
>
>    This is the equivalent in WF2:
>
> | <output id="f3" name="sum"
> | onforminput="value = (+x.value) + (+y.value)">0</output>
>
>    The <output> element has several advantages:
>
> 1) The control is never successful for form submission. Since all data
> sent to the server needs to be validated for security purposes, you'd
> have to redo the calculation server-side anyway, so submitting
> calculations like these only serves to encourage web authors not to
> validate the calculated value on the server. By contrast, <input
> readonly> can be successful as defined in HTML 4.01.
>
> 2) Using <input> elements for elements that should never receive user
> input directly or submit content is an abuse of the semantics of
> <input>. By contrast, the semantics of <output> are specially tailored
> for the purpose of calculated values.
>
> 3) On some web browsers, native widgets are used for <input> elements.
> As a result, CSS may not be able to fully style <input> elements. On the
> other hand, web browsers can style <output> in a manner similar to a
> <span>.
>
> === Min and max values ===
>
>    These attributes are supported in WF2.
>
> === Range controls ===
>
>    WF2 supports the "range" type and the |step| attribute.
>
> === Validation expressions ===
>
> XFT:
> | <input id="f2" name="y" datatype="number" constraint="y &gt; x"/>
>
> WF2:
> | <input id="f2" name="y" type="number" onchange=
> | "if (!(+value > +x.value)) {setCustomValidity("foo");return false;}">
>
> === Required fields ===
>
> XFT:
> | <input id="f2" name="y" type="text" needed="x != ''"/>
>
> WF2:
> | <input id="f2" name="y" type="text"
> | onformchange="required=(x.value != '')" >
>
> === Relevant groups of fields ===
>
> XFT:
> | <input id="f2" name="y" datatype="number" relevant="x &lt; 4"/>
>
> WF2:
> | <input id="f2" name="y" datatype="number"
> | onformchange="disabled=!(+x.value &lt; 4)">
>
> === Repeating fieldsets ===
>
> XFT:
> | <fieldset name="lineItem" repeat-number="4">
> | <legend>Repeating groups of fields</legend>
> | <label for="item">Product Name</label>
> | <label for="quantity">Number Purchased</label>
> | <label for="unitprice">Price Per Unit</label>
> | <input name="item" datatype="text" title="product name"/>
> | <input name="quantity" datatype="number" title="number purchased"/>
> | <input name="unitprice" datatype="number" title="price per unit"/>
> | </fieldset>
>
>    Note in the above, you have labels associated with multiple controls,
> which isn't possible in HTML 4.01. Also, one would expect the labels to
> pass focus if activated, but which <input> in the column would it pass
> focus to?
>
>    WF2 can duplicate this example with the added benefit of having a
> label for each control:
>
> | <fieldset>
> |   <legend>Repeating groups of fields</legend>
> |   <p id="order" repeat="template" repeat-start="4">
> |     <label>
> |       Product Name
> |       <input name="row[order].item" type="text">
> |     </label>
> |     <label for="quantity">
> |       Number Purchased
> |       <input name="row[order].quantity" type="number">
> |     </label>
> |     <label for="unitprice">
> |       Price Per Unit
> |       <input name="row[order].unitprice" type="number">
> |     </label>
> |   </p>
> | </fieldset>
>
>    Alternatively, you could consider this input tabular, so you could
> use a table with column headers:
>
> | <table>
> |   <thead>
> |     <tr>
> |       <th>Product Name</th>
> |       <th>Number Purchased</th>
> |       <th>Price Per Unit</th>
> |     </tr>
> |   </thead>
> |   <tbody>
> |     <tr id="order" repeat="template" repeat-start="4">
> |       <td><input type="text" name="row[order].item"></td>
> |       <td><input type="number" name="row[order].quantity"></td>
> |       <td><input type="number" name="row[order].unitprice"></td>
> |     </tr>
> |   </tbody>
> | </table>
>
> === Initializing fieldsets ===
>
>    Web Forms 2.0 not only supports adding, deleting and moving rows, but
> also supports initialization of both specific rows and rows that are
> generated on the client by the repetition model.
>
>    By contrast, XForms-Lite only supports initialization of the
> beginning rows, and doesn't yet support the addition, deletion and
> moving of rows at all. It may be a simpler repetition model, but only
> because it lacks power and flexibility.
>
> === Using radio buttons to determine relevancy ===
>
> XFT:
> | <input id="maiden" name="maiden"
> | relevant="gender=='female' &amp;&amp; married"/>
>
> WF2:
> | <input id="maiden" name="maiden"
> | onformchange="disabled=form1.namedItem('female')!='female' ||
> | married.value!='married')"/>
>
>    The WF2 version is definitely not ideal, though it may be an issue of
> my limited knowledge of Javascript...
>
> === Calculations involving selection fields ===
>
>    This particular example just seems to be a retread of previous  
> examples.
>
> === Calculations involving checkboxes ===
>
> XFT:
> | <input name="total" readonly="readonly"
> | calculate="crustPrice(size)+toppingPrice(size)*count(toppings)"/>
>
>    This is actually more difficult to do with scripting. Guess I'll have
> to use the Selectors API...
>
> WF2:
> | <input name="total" readonly onformchange=
> | "var size=+(document.matchSingle('input[name=size]:selected').value);
> | var toppings=
> | document.matchAll('.toppings input[type=checkbox]:selected').length;
> | value=crustPrice(size)+toppingPrice(size)*count(toppings)">
>
>    Not as compact, but it's manageable.
>
> === Referring to fields within named fieldsets ===
>
>    I don't really understand the point of this example. The fallback is
> suboptimal because values for the |name| attribute are reused in the
> same form. Furthermore, the user knows where the package is going
> because they just filled out the address. Also, you could have just had
> "fieldsetname.city" in the |name| attributes, which would have preserved
> fallback while at the same time allowing you to use the same value for
> |calculate|.
>
> === Editable selection lists (combo boxes) ===
>
> XFT:
> | <select name="fruit" id="f1" editable="12">
> |   <option>apples</option>
> |   <option>pears</option>
> |   <option>bananas</option>
> |   <option>pineapple</option>
> | </select>
>
> WF2:
> | <input name="fruit" id="f1" type="text" value="12" list="f2">
> | <datalist id="f2">
> |   Or select from the list:
> |   <select name="fruit">
> |     <option>apples</option>
> |     <option>pears</option>
> |     <option>bananas</option>
> |     <option>pineapple</option>
> |   </select>
> | </datalist>
>
>    Note above that <datalist> allows the markup to degrade in such a way
> that you still have the choice of using text input or a list. However,
> the fallback is optional:
>
> | <input name="fruit" id="f1" type="text" value="12" list="f2">
> | <datalist id="f2">
> |   <option label="apples"></option>
> |   <option label="pears"></option>
> |   <option label="bananas"></option>
> |   <option label="pineapple"></option>
> | </datalist>
>
>    Also, you can use the |data| attribute to prefill the <datalist> from
> an XML file.
>
>    I'm going to skip the rest of the sections.
>
> FINAL THOUGHTS:
>
> 1) DOM support for HTML Forms definitely needs to be improved to make
> certain tasks easier. (I suspect such improvements will be needed
> regardless of whether XForms-Tiny prevails against WF2.)
>
> 2) The best part of XForms-Tiny is that it give people the ability to
> write complex formulas in a simple, easy to understand format. I would
> suggest you submit your ideas on simple formulas in various attributes
> for inclusion in the next iteration of Web Forms (Web Forms 3.0).
> However, as I demonstrated above, the simple formulas used above do not
> require significant scripting, and are therefore not a sufficient reason
> to delay Web Forms 2.0.
>
> 3) XFT has a few nice features (like the formulas), but it's mostly
> redundant when compared to WF2 and in many cases is far more limited in
> its capabilities and fallback.
>
> 4) By the way, there is a pure Javascript implementation of the WF2
> repetition model. Check out the following link:
>
> http://weston.ruter.net/projects/repetition-model/
>
>    The Solar System example shows the WF2 repetition model being used
> without tables.
>

Received on Friday, 19 January 2007 13:01:18 UTC