W3C home > Mailing lists > Public > www-forms@w3.org > March 2007

Re: XForms Transitional

From: Dave Raggett <dsr@w3.org>
Date: Fri, 16 Mar 2007 14:08:43 +0000 (GMT)
To: Laurens Holst <lholst@students.cs.uu.nl>
Cc: www-forms@w3.org
Message-ID: <Pine.LNX.4.64.0703161329050.5334@localhost>
Hi Laurens,

Many thanks for the feedback, I have used it to improve the
draft XForms Transitional spec.

On Fri, 16 Mar 2007, Laurens Holst wrote:

> In Backbase 4.0, for this exact reason it is impossible (or at 
> least was, when I last was in the office, which is like 5 months 
> ago :)) to declare (using XML) new methods with parameter names 
> using reserved Javascript keywords. They are mapped to local 
> variables, and then eval-ed (or rather, new Function()-ed, iirc) 
> before executing the method body, and whenever you used e.g. 
> ‘with’ or ‘for’ it crashes.

I suspect that those people who are comfortable with XPath are 
likely to be in a position where they could take advantage of XForms 
as an XML application language, and exploit all the extra 
flexibility and power that it provides.

If they wanted to remain with HTML, then a reasonable solution would 
be to define a custom validity check as a handler for the changed 
event for the field in place of using the constrain attribute.

In regards to the ambiguity of dates like 2/1/2007 it is generally 
better to discourage that by using the month name or abbreviation in 
the presentation format. In this way the user gets immediate 
feedback upon entering the date and can correct it as needed.
Your eBay example illustrate the same point about the importance of 
providing immediate feedback and before submission. I once fell foul 
of this when booking a return flight and got the month wrong, so it 
is something I fully sympathise with.

> Yes, and from real customer cases at Backbase.com, I know that 
> customers have requested, and gone into production, with some 
> pretty strange and complex requirements. I mentioned one earlier 
> in a mail to public-html; the customer wanted error messages shown 
> in the content, but in two locations, directly below the input, 
> and in a summary at the bottom. What’s more, they wanted the 
> input messages to show up immediately, but the summary only when 
> the submit button was pressed.
>
> Now that last thing they wanted may be a little too much, but if a 
> simple yet powerful declarative means for error messages would be 
> created (think <message for="input_zip" error="pattern">Your zip 
> code needs to match the following patteren: 1234AB</message>), 
> instead of depending on red background and popup balloons, that 
> would be very interesting for a lot of application developers, and 
> also designers.

A message element is indeed a good idea. You would style and 
position it via CSS. The user agent or compatibility library would 
then reveal it when appropriate. Note that the title attribute can 
be used to provide a tool tip for labels and fields, and XForms 
Transitional avoids the need to set the same title attribute on both 
field and label. I now have to add support to my XForms Transitional 
compatibilty library and provide some working examples of it in 
action.

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Friday, 16 March 2007 14:09:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:09 GMT