Hi everyone,

I have a (technical) problem with middleware, and also I’d be grateful to hear 
some suggestions about the general workflow. Doubtless all of you are 
familiar with a topic as simple as POST handling, and maybe some of you have 
improvements over the usual Django approach.

So, I have a web application which (surprise!) has forms and is DB-driven. 
When designing the backend I considered the Django standard pattern for 
forms[1] and found it has problems such as coupling of unrelated things like 
showing a view and processing a form, and also it doesn’t provide a simple 
means of showing the same form in different places but having one POST 
handler.

Instead I chose another approach:
1. Every POST goes to the current URL (<form action="" method="post">);
2. On the server side, the URL of a POST is disregarded. The appropriate 
handler is chosen by the value of a special parameter (I called 
it “submission”, <input type="hidden" name="submission" />);
3a. If processing is successful, an HTTP 302 redirect is issued to the same 
URL;
3b. If not, form.errors are attached to the request object and the appropriate 
view is called, which has the opportunity of presenting the same form once 
more, specifying the errors.

To implement this I wrote a middleware class which is as simple as

class post_middleware(object):
    def process_request(self, request):
        if request.method != "POST":
            return None

        if "submission" not in request.POST:
            return None

        try:
            # successful POST always ends with a redirect
            return HttpResponseRedirect(do_submission(request))
        except invalid_form, e:
            request._dict_form_errors = dict_errors(e.form.errors)
            return None

So, it tries to handle the submission, and if that fails with an invalid form 
error, it returns None to let Django proceed with its usual procedure to find 
the appropriate view, which will then display the form again, complete with 
the erroneous input found in request.POST and the errors taken from the 
request object.

The implementation has not, however, been entirely successful.

So far Django modularity has allowed me to replace entire components with my 
own ones, or with 3rd party ones (like StringTemplate, which is superior to 
Django template engine), and integration was seamless. But I got all kinds of 
problems with this custom middleware. First of all, exceptions other than my 
custom invalid_form are no longer handled by the yellow screen of 
technical_500_response. Also, the transaction middleware no longer performs 
rollback on exceptions.

So could anyone please tell me how do I make Django handle middleware 
exceptions (do I have to wait until bug #6094 is fixed?), and also whether 
there’s another approach to handling form submissions with the above benefits 
and less drawbacks?

References:
[1] http://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view

-- 
TIA
Roman.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to