I added this under the WebWork cookbook.

BTW can we take a vote or something on releasing 1.3 officially?  I've been doing 
development with 1.2 for about a month now and there are a number of incompatibilities 
when switching to 1.3.  Nothing major but annoying nevertheless.  It is a little scary 
to depend on code being stable when the codebase is a moving target.

After releasing 1.3 how about creating a 1.3 branch in CVS to support bug fixes and 
minor enhancements like we discussed previously?  1.4 can then continue on the head.

-----Original Message-----
From:   Jason Carreira [mailto:[EMAIL PROTECTED]]
Sent:   Tue 2/4/2003 2:16 PM
To:     [EMAIL PROTECTED]
Cc:     
Subject:        RE: [OS-webwork] Graphical submit buttons and WW 1.2.1
Good question. I don't have an answer, but whoever figures this out,
please Wiki it too. :-)

> -----Original Message-----
> From: Kirk Rasmussen [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, February 04, 2003 3:50 PM
> To: webwork list
> Subject: [OS-webwork] Graphical submit buttons and WW 1.2.1
> 
> 
> Hi All,
> 
> I was wondering if someone has tried using multiple graphical 
> submit buttons on a single form?
> 
> For example let's say I have the following:
> 
> <form>
> <ui:textfield label="'Email'" name="'userID'" 
> maxlength="100"/> <ui:password label="'Password'" 
> name="'password'" maxlength="32"/>
> 
> <input type="image" src="/img/sign_on.gif" name="doSignIn" 
> value="Sign In" /> <input type="image" src="/img/update.gif" 
> name="doUpdate" value="Update Settings" /> </form>
> 
> If I had regular submit buttons (i.e. type=submit), the 
> dispatcher would call "setDoSignIn()" and "setDoUpdate()) 
> because the parameter name would simply be "doSignIn" and 
> "doUpdate" respectively.  
> 
> But in the case of graphical submit buttons the parameters 
> sent from the browser become "doSignIn.x" and "doSignIn.y" 
> and "doUpdate.x" and "doUpdate.y".  Other than making my 
> action ServletRequestAware and using the servlet request 
> directly  to look at the parameter is there a best practices 
> for dealing with this issue?
> 
> Thanks,
> Kirk Rasmussen
> Lucasfilm Ltd.
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 
> See! http://www.vasoftware.com 
> _______________________________________________
> Opensymphony-webwork mailing list 
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> 



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to