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