Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^2: Review: CGI::Prototype

by dragonchild (Archbishop)
on Dec 02, 2004 at 15:28 UTC ( #411791=note: print w/replies, xml ) Need Help??


in reply to Re: Review: CGI::Prototype
in thread Review: CGI::Prototype

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.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Replies are listed 'Best First'.
Re^3: Review: CGI::Prototype
by The Mad Hatter (Priest) on Dec 02, 2004 at 20:33 UTC

    I would have the first button have a small Javascripty-doo that changes the hidden runmode field from ActuallySubmit to AddAnother, then submit.

    dragonchild, I've never used C::A (or C::P), but why must the runmode be in a hidden field? Why not have the submit button be the runmode value? For example:

    <form action="blah" method="post"> <input type="text" name="data" value="Default data." /> <input type="submit" name="runmode" value="Save" /> <input type="submit" name="runmode" value="Add more data" /> </form>

    If the "Save" button is clicked, the "Save" runmode will be called. If the "Add more data" button is clicked, that runmode will be called.

    The only limitation is that either your button text or runmode names will be ugly.

      It's not completely bad since you can have the same form submit to different run modes with the same data without having to do some javascript hacking, but it does have it's down side...

      If you change the wording on the button (to be more user friendly, etc) then you also have to change the perl code on the backend to have that same name as the run-mode. not horribly difficult, but it means that a purely design change would need a change to the perl.
        If you change the wording on the button (to be more user friendly, etc) then you also have to change the perl code on the backend to have that same name as the run-mode. not horribly difficult, but it means that a purely design change would need a change to the perl.

        I use a custom run_mode that allows me to use the name of the button instead of the value which gets around this problem. It also allows the use of image buttons.

        William
      I've been doing that for quite some time. The CGI::Application concept of runmodes (state transitions) seems to work best if there is only one runmode the user can go to next. In my case, there are multiple buttons on the page, each of which needs to transition to a different runmode. So, in my CGI::Application::setup routine, I define a hash that shows the mapping of how to do the transitions. Transitions depend not only on the name of the submit button but a hidden parameter that holds the last runmode (e.g. where we came from) since different runmodes could use the same button name to do different things. For example, I might have this in my setup routine. Note, I find the term "runmode" non-intuitive so in my applications I use the term "state".
      $self->mode_param(\&which_state); $self->{DISPATCH_SUBMIT} = { 'state_main' => { ' Create new question ' => 'state_new_question', ' View all questions ' => 'state_view_all', }, 'state_new_question' => { 'Add question' => 'state_add_question', 'Cancel' => 'state_main', } }
      The first entry in the hash is the the state the user just came from. The next level in the hash is the name of the submit button and then what runmode subroutine to call. Then in my application, there's a method called which_state which looks at the last state and decides what to do next. If a runmode has only 1 possible transition, then it can set the runmode (state) value directly and bypass this mechanism. This has worked quite well for me. A possible downside is that the name of the submit button (which some might argue is content) is embedded in the code so a change to the page requires a change to the code. In my case, I manage both content and code so I have not been hindered by this.
      the runmode is determined by a CGI parameter, usually named 'rm'. Because of that, it usually is a hidden input called 'rm' with the name of the next runmode as its value.

      The Submit buttons sound like an interesting idea ... There are a few interesting quirks to it, but it looks like it could be made to work. ++!

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        You get into namespace issues. It's easy to give two submit buttons the same value in your application that are supposed to go to different runmodes. In a large application, you'll probably run out of good names eventually.

        I always felt that HTML using the "value" param on submit buttons was a bad design choice, and I think this illustrates that problem well. This, of course, is HTML's problem, not C::A's.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      >I've never used C::A (or C::P), but why must the runmode be in a hidden field? Why not have the submit button be the runmode value?

      That's what I do in C::A. My POST url looks something like "/cgi-bin/profile?area=acc" to signify that the form is submitted to the "profile" script, and is intended to access the sub-page "account settings." I suppose "area" is a run-mode. But, I go further, using the submit button's value to internally choose a runmode. My C::A code looks something like
      if (defined($q->param('area'))) { if ($q->param('area') eq 'acc') { if (defined($q->param('change_psw'))) { $self->start_mode('21'); } # end form to change password was submitted elsif (defined($q->param('change_acc'))) { $self->start_mode('22'); } # end form to change account settings was submitted elsif (defined($q->param('send_verify'))) { $self->start_mode('23'); } # end form to verify email address was submitted else { $self->start_mode('2'); } # end there was no submit, profile-account page should be displa +yed } # end profile area = account else { $self->start_mode('1'); } # end no profiel area was provided, profile main page should be disp +layed
      The idea here is that the "area" takes me to a specific sub-page for "profile" (account settings, my personal info, description, photos). If area is not set (or unintelligible), the main profile page is displayed (as if it's an initial display). If an area is specified, then if submit buttons (there may be more than one form on a page) set the run mode to process whichever was pressed. If no submit button was pressed, it's an initial display of the page (for that area). It works well for me. It gets ugly with long nested if/elsif structures. Followed by a long self->run_mode hash associating the numeric codes to the subroutines. I can see that CGI::Prototyle could make this more natural through inheritance. But, I like being able to see all the details and understanding how it works. OO is elegant but I still have trouble thinking in those terms.

      Mark
        My POST url looks something like "/cgi-bin/profile?area=acc"

        The last time I looked, CGI.pm required a code change to allow both POST and GET style params on the same request (an easy "uncomment this line" change, but a change regardless). Has that changed, or did you modify your CGI.pm?

Re^3: Review: CGI::Prototype
by perrin (Chancellor) on Dec 02, 2004 at 20:02 UTC
    Please elaborate further - WHAT doesn't C::A do?

    Well, it hardly does anything at all, wouldn't you agree? It's just a dispatch table. All of the interesting stuff is in plugins to add Data::FormValidator and friends. That's not a negative to me. I think most people are going to build more on top of C::A if they use it for anything significant.

•Re^3: Review: CGI::Prototype
by merlyn (Sage) on Dec 02, 2004 at 15:35 UTC
Re^3: Review: CGI::Prototype
by hardburn (Abbot) on Dec 02, 2004 at 15:38 UTC

    I would have the first button have a small Javascripty-doo that changes the hidden runmode field . . .

    Where I work, we have a significant number of users with JavaScript turned off (and it's staying off, as a lot of them are government users in departments with standing policies of not having JavaScript on).

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re^3: Review: CGI::Prototype
by simon.proctor (Vicar) on Dec 03, 2004 at 12:48 UTC
    You can set the runmode via the submit button provided you make the value of your run mode "human readable". Something like:
    <input type="submit" name="rm" value="Update users" >
    So no javascript required.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://411791]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2021-06-24 10:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (125 votes). Check out past polls.

    Notices?