Re: Submit-on-enter example

Hi Mark,

Do you key off of DOMActivate specifically?  Is the handling xf:input 
specific?  What if I use formsPlayer to load a xf:select1 trigger a 
submission via xf-select?  Would the data be updated prior to the 
submission?  What if @incremental="false"?  Just wondering if we choose 
to be compatible with formsPlayer, when do we need to do the update of 
the instance data?

Any guidance appreciated,
--Aaron

Mark Birbeck wrote:
> 
> 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:
> 
>  <http://www.formsplayer.com/how-to/toolbar-prototype>
> 
> 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.)
> 
> Regards,
> 
> Mark
> 
> 
> 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.
>>
>>
>>
>>
>>
>>
> 
> 

Received on Thursday, 15 February 2007 23:14:24 UTC