On Sun, 2009-01-04 at 12:03 +0200, Roman Odaisky wrote:
> 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.
I think you're letting yourself be too constrained by what is only a
fragment of example code. The only requirement is that a view is called
and the form data should be validated somehow. The documentation is
necessarily short in order to not overwhelm the explanation. It also
does represent a fairly common pattern where a particular form is only
processed by a single view. But that doesn't mean it's the only way to
do that.
You can and should split up your code into separate functions however
you like. Form validation can be done in a separate function that
returns a dictionary that is used to update the context of the calling
view, for example. Your alternate solution sounds a bit complex for
working around the things you've described, but c'est la vie...
[...]
> So could anyone please tell me how do I make Django handle middleware
> exceptions (do I have to wait until bug #6094 is fixed?),
Since #6094 is about handling exceptions in middleware, and you want
exception handling in middleware to work as described in #6094, the
answer to your question is "yes".
> and also whether
> there’s another approach to handling form submissions with the above benefits
> and less drawbacks?
I don't really understand all the stuff about ignoring the URL in your
solution, so maybe the alternate solutions will lose some of the
constraints you have in your system. Adding an extra hidden field to the
HTML as a way to fake out the server-side code sounds inelegant to me,
however. You already have the action attribute on the form to specify
what should process the result; the hidden field is semantically
redundant. One approach I use with some regularity, as I said above, to
put the form validation into its own utility method and have that method
return a dictionary of context updates (perhaps the form with errors
included) and an indicator as to whether to redisplay the existing page
(for error redisplay) or move on. The view knows where to redirect to,
since that's view-sensitive, not form-sensitive, so the form validation
function doesn't need to worry about that. It just returns, basically,
thumbs up or thumbs down, plus some context information. For example
(abbreviated):
def view_func(request, ....):
context = {}
# ... (other processing here)
# This call returns True if the form needs to be (re)displayed
result, data = process_login(request)
if not result:
# Successful login
return http.HttpRedirectResponse(....)
context.update(data)
# ... (other processing here)
return render_to_response(...., context, ....)
In this case, the process_login() function is view-agnostic. This
example is actually pretty contrived, since for something like login,
the action attribute on the form would send the submission to the more
or less unique view that handles logging in, so it doesn't need a call
out. Name/address entry for registration or data entry is a case where I
do seem to use this pattern a bit, though, just scanning through my code
repositories.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
