Thanks John,

For the record also please note that I'm also trying this in some test
html pages (posting to php to print the post variables) and with only
1 submit button the problem exists... I have 2 forms where in one IE7
posts the button and another where it doesn't post, this is just
mad...

I can't use _eventName because my form has 2 submit buttons that go to
different events... So... what are my alternatives?

TIA


On Wed, Apr 8, 2009 at 6:44 PM, Newman, John W <[email protected]> wrote:
> Sorry I can't really answer your question, but we gave up on submit button 
> names a while ago.  Nice idea but it is a bit messy due to browser quirks, 
> form serialization for ajax, and enter key submit.  Two submit's on the same 
> page should work, but IIRC IE 6 and 7 do different things depending on number 
> and types of fields on the form.  When we noticed this, I mocked up some test 
> html pages, a lot of these combinations behaved differently and the submit 
> name was deemed 'too unreliable' between gecko and ie6/7:
>
> One text field
> One text field one submit
> Two text fields one submit
> Two text fields two submits
> One select field one submit
> Etc
>
> Instead of even bothering to understand all these quirky 'rules' we opted to 
> just to manage the _eventName parameter in any requests.  I'm curious if 
> anyone has NOT run into issues with the default handler firing unexpectedly 
> despite use of <stripes:submit name="notdefault" />.
>
> The source of the event name has always caused a bit of confusion for me - 
> the backend code around this was cleaned up recently, but IMO this,
>
>     * <p>
>     * Failing that, search for a parameter in the request whose name matches 
> one of the named
>     * events handled by the ActionBean. For example, if the ActionBean can 
> handle events foo and
>     * bar, this method will scan the request for foo=somevalue and 
> bar=somevalue. If it finds a
>     * request parameter with a matching name it will return that name. If 
> there are multiple
>     * matching names, the result of this method cannot be guaranteed and a
>     * {...@link StripesRuntimeException} will be thrown.
>     * </p>
>
> should not exist anymore..
>
> Don't forget about the enter key =)  also prototype.js needed a patch to get 
> submits into form.serialize()...
>
>
> -----Original Message-----
> From: Paulo Silva [mailto:[email protected]]
> Sent: Wednesday, April 08, 2009 1:18 PM
> To: [email protected]
> Subject: [Stripes-dev] Submit form in IE doesn't send the correct event
>
> Hi,
>
> I have a form that has 2 submit buttons (one to one event, another
> goes to another).
>
> Everything works alright except when I press enter to submit the form in IE7.
>
> If I do that the button name isn't posted so Stripes goes to the
> default handler instead of the correct event.
>
>
> This also happens if I have only 1 submit button. My form has 1 select
> and 2 input fields. I did the exact samething for other forms and they
> work correctly, I don't understand why IE7 doesn't send this
> information sometimes.
>
>
> Anyone has a clue?
>
> TIA
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to