Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: Review: CGI::Prototype

by The Mad Hatter (Priest)
on Dec 02, 2004 at 20:33 UTC ( #411937=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^3: Review: CGI::Prototype
Download Code
Re^4: Review: CGI::Prototype
by dragonchild (Archbishop) on Dec 02, 2004 at 20:37 UTC
    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 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.

        Actually, it is Microsoft's problem. HTML has the buttom element which allows you to seperate the form value from the buttom display. IE6 messes it up, though. Otherwise, you could do something like:

        <button type="submit" name="runmode" value="doform1">Send Form</button>
Re^4: Review: CGI::Prototype
by mpeters (Chaplain) on Dec 02, 2004 at 21:00 UTC
    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
Re^4: Review: CGI::Prototype
by RhetTbull (Curate) on Dec 03, 2004 at 17:18 UTC
    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.
Re^4: Review: CGI::Prototype
by mfuller (Novice) on Dec 04, 2004 at 21:14 UTC
    >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?

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2014-08-31 04:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (294 votes), past polls