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

Re: Submit-on-enter example

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 15 Feb 2007 21:09:22 +0000
Message-ID: <640dd5060702151309v6d29b7bdte882e0d90db86369@mail.gmail.com>
To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
Cc: www-forms@w3.org

Hi Leigh,

Sorry for being dim, but I'm afraid I don't quite follow this question:

> Do any XForms processors have a way of interpreting the event sequence
> that makes this popular example work as is?

If you mean, is there a handler that one could write for DOMActivate
that could be used to set the value and invoke the submission, then I
can't think of one that wouldn't upset the UI. (By which I mean things
like navigating out and back in again would put the cursor in a
different position, etc.)

If on the other hand you mean, do other processors support the
behaviour you desire, then formsPlayer has done for a long time. It
was originally implemented so that we could create compact toolbars
for IE, using XForms, but we actually find we use it quite a lot. A
recent example is here:


It's an IE toolbar that provides access via a search box to the Ajax
prototype documentation.

Running your example works fine in IE+fP with Sidewinder installed (so
that you can use .xhtml).

By the way, @incremental is not a solution, without DOMActivate
writing the value, since spec doesn't enforce the way incremental
behaves. It's therefore possible that the data won't have been updated
in the model when the DOMActivate is received, if a processor chooses
to not update on every character typed. (Updating on every character
is very sluggish when trying to implement something like Google
Suggest, which uses the network.)



On 15/02/07, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote:
> For many years now, we've had an example of using DOMActivate to submit
> on "enter key" in a device-independent way.
> Although it's done in a device independent way, for convenience I'll
> just refer to the enter key throughout this message.
> This example is even written up in Micah Dubinko's book:
> http://xformsinstitute.com/essentials/browse/ch10s03.php#ch10-15-fm2xml
> I typed up a version of this example, which just submits via GET back to
> itself so you can inspect the resulting URI:
> http://xformstest.org/klotz/2007/02/return.xhtml
> If you type something in the box and either press enter or submit via
> the trigger, it's supposed to submit via GET to
> http://xformstest.org/klotz/2007/02/return.xhtml?value1=something;value2
> =test
> Unfortunately, it appears not to work in popular XForms processors.
> If you submit via pressing enter, it doesn't submit value1:
> http://xformstest.org/klotz/2007/02/return.xhtml?value2=test
> Aaron Reed pointed out to me that this is for two reasons:
> 1. When you press enter, you aren't exiting the form control and the
> value doesn't get changed, unless the input is oncremental.
> 2. Less importantly, the submission spec calls for non-empty values to
> be dropped instead of being submitted as empty values.
>    (Personally I disagree with this spec language and would have
> preferred xsi:nil to apply, but I didn't notice so it's
>     probably too late.)
> So, here's a version with input/@incremental='true' which does provide
> the desired behavior:
> http://xformstest.org/klotz/2007/02/return-incremental.xhtml
> I don't think there is an event we can dispatch inside the DOMActivate
> handler to cause the value to change, but maybe I'm wrong.
> Do any XForms processors have a way of interpreting the event sequence
> that makes this popular example work as is?
> Leigh.

  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Thursday, 15 February 2007 21:09:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:55 UTC