I'm curious as to why javascript is frowned upon so much for
solving this problem. I don't particularly like javascript that
much, but in some cases, it presents a reasonable solution to
this problem. While WebWork commands are definitely the way to
go in a lot of cases, if you do have to worry about i18n or you
have commands with multiple words in them, then I think
javascript is an appropriate choice. Something like this:
<input type="submit" value="Add Item"
onclick="javascript:doAddItem();"/>
and your javascript function would be:
function doAddItem() {
document.someForm.action="<ww:url page="<name of command>"/>";
document.someForm.submit();
}
I believe this is standard Javascript that will work across all
browsers, though I am not 100% sure about that. Has anyone had
an experience where this doesn't work?
To me, the problem of multiple submit buttons in an HTML form
is due to a problem with the view technology. If HTML submit
buttons also had a "displayValue" attribute where you could
define what is displayed on the button separate from the value
of the button as a parameter, then you wouldn't have to worry
about messing with javascript, and you could easily use WebWork
commands to solve everything. But since the problem lies in the
view, why not solve the problem in the view and not have to
jump through all sorts of hoops to solve the problem elsewhere?
Rob
---- On Tue, 11 Mar 2003, Steve Conover ([EMAIL PROTECTED])
wrote:
> I was going to save this until I tried it out, but since
there's some
> discussion I'll go ahead and throw this out there.
>
> Taking this example
>
> <form action="dummy.action">
> <input type="text" name="foo"/>
>
> <input type="hidden" name="cancelCommandValue"
value="redirect_to_index"/>
> <input type="submit" name="cancelCommand" value="Some
localized save
> text"/>
>
> <input type="hidden" name="saveAction" value="save_foo"/>
> <input type="submit" name="saveCommand" value="Some
localized save text"/>
> <!-- Notice this gets around the input type=submit value
problem
> using naming conventions and a hidden field -->
> </form>
>
> Write an ActionFactoryProxy (called something like
> "DispatcherActionFactoryProxy" - goes at the top of the
factory stack)
> that looks for a parameter named *Command. If it finds it,
look for a
> params named [commandname]Action. Use the value of that
parameter as your
> action name.
>
> Some might argue that the actions shouldn't be specified in
the view.
> Well for one, they already are (i.e. in every form tag), plus
I have yet
> to convince myself that another level of indirection is
necessary (i.e. in
> place of putting the actual actionname in the hidden field,
you put
> something like "save" or "cancel" and have a mapping layer on
the server
> side that determines what actual action to use). IMHO the
separation
> between M and VC is the main thing.
>
> I'm trying to avoid polluting my commands with a bunch of
controller
> logic, or alternatively creating a ton of extra controller
classes to do
> branching logic - maybe this is a viable solution.
>
> Anyway that's my current thinking. Thanks for all the
replies.
>
> Regards,
> -Steve
>
> > Hi all,
> >
> > I brought this issue up a long time ago. My work
> > around is to name the submit button as
> > command{commandName}. Webwork would extract the
> > commandName out from the name, and invoke appropriate
> > doXXX method.
> >
> > --- Rickard_Öberg <[EMAIL PROTECTED]> a écrit : >
> > Jason Carreira wrote:
> >> > Set the button names to all be "command" and set
> >> the value to the name
> >> > of a command in your CommandDriven Action and have
> >> methods named
> >> > doSave,doCancel, etc.
> >>
> >> This does not work well with an i18n'ized app, and
> >> also doesn't work if
> >> the button name has several words.
> >>
> >> It's a very tough issue, and I don't have any better
> >> answer though...
> >>
> >> /Rickard
> >>
> >>
> >>
> >>
> > -------------------------------------------------------
> >> This sf.net email is sponsored by:ThinkGeek
> >> Welcome to geek heaven.
> >> http://thinkgeek.com/sf
> >> _______________________________________________
> >> Opensymphony-webwork mailing list
> >> [EMAIL PROTECTED]
> >>
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-
webwork
> >
> > =====
> > -------------------
> > Hai Pham Quang
> > -------------------
> >
> > __________________________________________________________
> > Lèche-vitrine ou lèche-écran ?
> > magasinage.yahoo.ca
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:Crypto Challenge is now
open!
> > Get cracking and register here for some mind boggling fun
and
> > the chance of winning an Apple iPod:
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-
webwork
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now
open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-
webwork
>
>
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
