|
|
|
| Perl Monk, Perl Meditation | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
Our app will have to figure out which button was hit and handle the data and output as needed. In C::A, there is really only one place you can put this logic: cgiapp_prerun(). If you have many runmodes that need this sort of functionalilty, your cgiapp_prerun() can start getting rather large.
Why do both buttons go to the same runmode when they don't do the same thing? I would have the first button have a small Javascripty-doo that changes the hidden runmode field from ActuallySubmit to AddAnother, then submit. Then, you let C::A do the work of determining which button was hit using its native dispatching mechanism. No need for any cgiapp_prerun() nonsense. You're not letting C::A do what it's supposed to do. When you get a hit, you need to get parameters, validate them, do something with them, and return the output. In C::A, all this has to be done within the single subroutine that defines the runmode. You could have your runmode being a simple dispatcher to other subroutines, but somehow this just doesn't satisfy me. There are dozens of plugins that do exactly what you're trying to have the runmode do. Form validation, parameter getting, etc ... all of these are solved problems. I'm going to agree with merlyn that C::A doesn't quite go far enough. Please elaborate further - WHAT doesn't C::A do? Being right, does not endow the right to be rude; politeness costs nothing. In reply to Re^2: Review: CGI::Prototype
by dragonchild
|
|