in reply to Form actions and browser refresh on PM

Even if the action= was changed for a form, that wouldn't make using "refresh" behave any differently (at least not in any browsers that I use). It would, however, allow you to reselect and then reactive the displayed URL in order to refresh.

You can't refresh (without resubmitting the form) because the browser doesn't know whether the URL makes sense as something to just GET when it was given in order to POST to, so a sane browser won't GET a URL when requested to refresh a page that was displayed after a POST.

Now, what you suggest is probably a good idea and, if done properly, would probably eliminate some of the many minor glitches like chatting making scratch pad viewer reset (any PerlMonks page that requires more than just node_id= to determine what to display will be "reset" when you submit from that page such as to vote or to chat).

        - tye (but my friends call me "Tye")
  • Comment on (tye)Re: Form actions and browser refresh on PM

Replies are listed 'Best First'.
Re: (tye)Re: Form actions and browser refresh on PM
by shotgunefx (Parson) on Oct 02, 2001 at 15:33 UTC
    One thing that may be easy to implement (I haven't looked at the Everything code) that would solve the problem of "which" form was submitted would be to have the parameter not named action, but action.UrlEncodedExpectedParamNames.

    Then you could sublcass CGI to only read in the params you want in _init by looking at the action.something parameter. Of course, you would have to define the expected params for each form action to differentiate between params that existed in the URL as opposed to being posted. You could probably make better use of this but I think this way would be pretty easy to shoehorn in to the source.

    -Lee

    "To be civilized is to deny one's nature."
[reply]

      I think you misunderstand the problem. The challenge isn't how to ignore extra parameters that don't apply to the form being submitted (all of the forms here already know which parameters they care about and happily ignore the rest), but nearly the opposite: getting forms to preserve extra parameters so that the forms cooperate better.

      Take, for example, the scratch pad viewer. After you get there, you can enter a username and click Submit and you'll see that user's scratch pad (if possible). While looking at that scratch pad, click the Talk button in the chatter box. The screen will refresh and you won't see the selected user's scratch pad anymore. This makes it rather difficult to discuss the contents of someone's scratch pad with them (without resorting to a separate window for chat).

      The problem is that the first submit adds a "user=tye" parameter that isn't preserved by the "Talk" submit. Even if you enter "&user=tye" into the URL, PM submits are hard-coded to only preserve "node_id" parameters so the same problem persists. Changing PM's form generation code to either add (most?) current parameters to the "action=" attribute of forms or to add them as hidden input fields would fix this problem (though a general solution for this won't be trivial).

              - tye (but my friends call me "Tye")
[reply]
[d/l]
        Ahh, my bag, that is different then. When faced with a similar problem, I modified the form and self_url functions to include params that should persist.

        -Lee

        "To be civilized is to deny one's nature."
[reply]

In Section Perl Monks Discussion