- From: Aaron Reed <aaronr@us.ibm.com>
- Date: Thu, 15 Feb 2007 17:10:04 -0600
- To: www-forms@w3.org
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