W3C home > Mailing lists > Public > public-appformats@w3.org > September 2006

Re: A forms-lite straw man

From: Dave Raggett <dsr@w3.org>
Date: Tue, 5 Sep 2006 23:27:56 +0100 (BST)
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, www-forms@w3.org, public-appformats@w3.org
Message-ID: <Pine.LNX.4.64.0609052313370.5310@holly>

On Tue, 5 Sep 2006, Henri Sivonen wrote:

> On Sep 5, 2006, at 19:33, Dave Raggett wrote:
>> On Wed, 6 Sep 2006, Lachlan Hunt wrote:
>> Another key difference is that in WebForms 2.0 the data is owned 
>> by the field, thus a field can state which forms it belongs to. 
>> It is better software engineering for the field to act as a view 
>> onto the data. Decoupling the view and the data makes it easier 
>> to support structured data and to describe calculations for 
>> derived fields and other purposes.
> It is possible and even convenient to use JavaScript closures 
> attached to the DOM nodes of form fields for binding the form 
> fields with an XHR-load/saved data model document tree. Such an 
> arrangement has the benefit that it is backwards-compatible with 
> existing Web browsers (including IE6).

But why go to such difficulties when a declarative solution is
achievable? A cross platform JavaScript libarary can provide
support for existing browsers, enabling authors to focus on
declarative markup rather than scripting. Also from what I hear,
many developers are having trouble with Ajax and XHR.

>> If the expression evaluates to false, the field is considered to 
>> be invalid. I got the name wrong and it should have been called 
>> validate. The expression could act over just the field's value, 
>> but it could also refer to the values of other fields. It could 
>> even call out to a function defined as part of a web page script.
> What is the advantage over calling a JavaScript function from the 
> onchange handler? 
> http://whatwg.org/specs/web-forms/current-work/#setcustomvalidity

If you are good at maintaining custom JavaScript, then perhaps the
benefit is less valuable to you, but a simple expression will be
easier to check for others.

>> WF2 essentially limits to boolean literals, and you cannot 
>> describe the conditions under which a field is required. For 
>> example, your parent's name might be required if your age is 
>> under 15.
> The onchange handler of the age field can invoke a JavaScript 
> function that toggles the required attribute on the name of parent 
> field.

Sure, a Turing complete procedural solution is indeed very powerful,
but that's the point. A more constrained approach is easier to
verify against the application requirements.

>>> The WF2 output element uses a JavaScript expression to evaluate
>>> to a string.  What benefit does an XPath expression provide
>> It is more declarative than calling out to a JavaScript function.
> Why is that a benefit?

Same as above. I guess I won't be able to convince you of the
benefits of declarative representations.

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
Received on Tuesday, 5 September 2006 22:28:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC