This is really more of a question about how PM (or Everything) operates, so if you think it would be more appropriate in SOPW, feel free to move it there.

I first noticed this in the context of voting on nodes, but as far as I've looked, it's true of all PM pages. All the forms use the POST method and their action is /index.pl. Thus, after you submit the form (such as to record your votes) and the new page loads, the URL in your browser no longer reflects the node name or node_id which is being displayed. Among other things, hitting refresh won't work.

My question is, why does it work that way? It seems like when Everything is generating the page, it could modify the action in forms as it does for anchor links in the page. That is, forms would end up looking like this: <form method="POST" action="/index.pl?node_id=...&lastnode_id=..."Then after you vote (or whatever), browser refresh would still work. Since the form uses POST, the code that parses the form data could just ignore the GET "parameters".

Some reasonable answer formats I can think of:

I don't have a lot of web experience, so I apologize if this is patently obvious.

TIA

Replies are listed 'Best First'.
Re: Form actions and browser refresh on PM
by chromatic (Archbishop) on Oct 02, 2001 at 01:31 UTC
    I guess Everything *could* change the action parameter, but it doesn't work that way. Instead, any page element that contains a form is supposed to call a startform htmlcode or wrap itself in a formcontainer. These just provide a hidden node_id parameter with the current node id. Otherwise, forgetful Everything developers will spend a lot of time wondering why they keep getting the default node during form debugging. (Explained without a <emphasis>hint</emphasis> of bitterness.)

    As for ignoring GET parameters when a form is POSTed, that's really not an option. Everything uses CGI. :) In fact, I'm not sure exactly what GET parameters in an action attribute are supposed to accomplish. Nor am I certain what a browser refresh/reload is supposed to do. Time for a trip to the relevant RFCs, perhaps.

    My inclination is to say that any user agent which doesn't accurately recreate the information sent to the server when reloading the current page is broken. If your web browser uses what's displayed in the Location bar instead of what was sent via POST, that counts as broken. :)

[reply]
(tye)Re: Form actions and browser refresh on PM
by tye (Sage) on Oct 02, 2001 at 01:45 UTC

    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")
[reply]
      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]

Back to Perl Monks Discussion