- 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
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:04 UTC