[mod_python] Approaches to handling input forms.

Graham Dumpleton wrote:
> Imagine there is a form for logging into a site and its url is at "login". I've
> ignored extensions in this discussion as different mechanisms may or may
> not make it easy to use them.
> Is there a tendency to have the form when submitted, post back using
> the same url, ie., ACTION field in form is not set, or to a different url.

Your wording is mildly confusing here - let me see if my morning-addled 
brain has managed to interpret this correctly.

Your server has returned to the user an HTML page with a form in it, at 
a url of "/login".  The user is now submitting a response to this form, 
and you're asking where people tend to have such things submitted?  I'll 
be going with the assumption that this is what you're asking.

> In this approach you tend to end up with a lot of things jumbled up into
> one content handler and it could perceivably get a bit messy.

I've taken the approach that producing content in response to a GET 
request is an entirely separate action to taking an action in response 
to a POST request.  This means I've got very clearly separated view code 
and action code; you can consider this an MVC approach, where a POST 
handler is controller logic, and a GET handler is view logic.

A POST action handler will do its work, and return status information 
and a GET location.  Currently, I just pretend at this point that the 
request was that GET originally, because that makes including the POST 
result information trivial, but I plan to use an external redirect using 
an HTTP/1.1 303 code, since this has all the behaviours I desire: Back 
works, reloads don't resubmit the POST, and the URL location bar 
reflects what the user is seeing.

For HTTP/1.0 clients, the 302 does more or less the same thing.  Some 
browsers are just too ancient to do the right thing no matter what you 
do, and I tend not to worry about them.  If it's a specific requirement 
that you need to support pre-1998 browsers, you probably want to keep 
the entire system as trivially simple as possible anyway.

(Bad enough that we still need to support Internet Explorer, which is 
stuck in the 90s as far as standards are concerned.)

> If the form and the processor of the form are at different urls, there is a
> better separation of functionality of presenting the form and its processing.
> Being different urls though, you might have to be a bit trickier as far as
> using redirects to get back to where you want when login is sucessful
> especially if it is a generic login processor.

They can be at the same URL just fine, if you're distinguishing between 
a POST and a GET.

-- 
bje