- From: Dave Raggett <dsr@w3.org>
- Date: Sat, 21 Oct 2006 11:57:37 +0100 (BST)
- To: Mark Birbeck <mark.birbeck@x-port.net>
- Cc: www-forms@w3.org
Many thanks Mark for responding to my posting. I agree with you that the architecture in XForms is more important than its syntax. The stepping stones I have been exploring are about how to make use of that architecture with only incremental extensions to the HTML forms syntax, and to do so in a way that can be used today with existing browsers without the need for plugins. The experiments are intended to explore opportunities for stepping stones between the capabilities provided by HTML4 and those provided by XForms. In particular, the means to use simple expressions for validating field values and spread-sheet like formulae for computed fields, but also the means to describe repeating groups of fields, e.g. for line items in a purchase order. All this should be possible without the author needing to write any lines of client-side script. So how to do that? I chose to stick with the existing HTML4 form, fieldset, input, select and button elements, and to consider what new attributes could provide the desired behavior. In essence, this meant grafting attributes taken from the XForms bind element on to the HTML4 input element. Thus type, pattern, validate, required, relevant, and calculate. The idea is that the XForms model and associated constraints can then be readily generated from the HTML elements. The HTML input element already defines a type attribute so it was a matter of adding new values, and my experiments looked at doing so for number and date. This worked fine on IE and Firefox, but for it to work on Opera it proved necessary to use another attribute name to work around Opera's implementation of WebForms. I also borrowed min, max and step from Web Forms 2.0, for use with an experimental range control. Perhaps you can help provide a mapping for the step concept into XForms bind constraints? Essentially, the value needs to be constrained to be min value plus a multiple of the step, and be less than or equal to the max value. I also implemented min and max to work with dates, but didn't get as far as implementing min, max and mask as facets on strings, but did add support for regular expressions with the pattern attribute. The HTML forms data model in current browsers allows for repeated fields with the same name and models these as an array. This made it practical to implement repeating nodesets. The HTML fieldset element seemed like an obvious choice for a container, and I just added name and repeat attributes. The name would map to the nodeName for the corresponding container in the XForms model. The repeat attribute is presentational and controls the number of rows initially presented in the user interface. That raises some interesting questions about the back and reload semantics for browsers, but I will leave that for a later discussion. This leaves us with the question of the syntax for the expressions used with the validate. I chose to stick with a flat space of names for fields since this is what is browsers currently support. XForms 1.0 supports a richer model of data, and when this is needed that would provide a compelling reason for migrating your web application to the full XForms syntax. Staying with a flat namespace for forms-lite therefore seemed like a good compromise, and avoids getting drawn into the arguments between those who like and those who don't like XPath. From the point of view of expediency, I used a technique which meant I could exploit the JavaScript eval mechanism to evaluate expressions. This involved rewriting the expressions when the form was loaded to enable the direct use of eval. After a detailed study of what it takes to support new elements in existing browsers, I chose not to implement an output element. In practice, the input element can be used instead, and can be set to be read only if needed. This raises a question of how to allow user entered values to overrride the calculated value for a given field. This is used, for example, in expense claims to override the currency exchange rate. The data model needs to keep track of when an explicit value has been provided. I would like some help in understanding how this can be expressed with XForms 1.0/1.1. Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Saturday, 21 October 2006 10:57:45 UTC