On Thu, 2009-01-15 at 04:13 -0800, coulix wrote:
> Hi,
>
> I use a formWizard for a signup process:
>
> url(r'^signup/student/$', SignupStudentWizard([SignupForm,
> StudentForm]),
> {'extra_context':{"type":"student"}}, name='signup_student',),
>
> Now, used as it is it works fine.
> However in one case i need to pass extra_context data at run_time, to
> display the signup page and a message related to an invitation.
>
> I tried the following:
>
> View
> return HttpResponseRedirect(reverse('signup_student', kwargs=
> { 'extra_context': {'message':'woot',} }))
>
> It fails:
> NoReverseMatch at /account/invite/qsd/
>
> Reverse for 'signup_student' with arguments '()' and keyword arguments
> '{'extra_context': {'message': 'woot'}}' not found.
Hopefully this wasn't too surprising. Reverse() is designed to construct
URL patterns. The extra_context isn't part of the URL pattern. Different
values of extra_context do not generate different URL patterns, so
there's no way to tell from the string returned by reverse what the
pattern is.
>
> How would you approach the problem ?
If the URL string has to depend on a particular argument, that argument
has to be part of the URL pattern. That is, when the argument changes,
so must the URL string that is generated. This is a well-known
limitation of Python: it cannot read your mind.
Alternatively, put the extra data into the user's session. Or put the
extra data into the query string portion of the URL. Reverse doesn't
handle query strings (maybe in the future, but certainly not at the
moment), so you could do this:
from django.utils.http import urlencode
def my_view(....):
url = "%s?%s" % (reverse(....),
urlencode({"extra_context": ...}))
In this case, the value you use for extra_context has to be something
that can be expressed in a URL string. In your code fragment, you seem
to be hoping that a Python dictionary can be serialised back and forth.
That's probably optimistic (although you might be lucky and have it
work). If you want to pass around Python objects, definitely use the
session, which can pickle things.
Note, also, that the fragment I've written uses
django.utils.http.urlencode, not urllib.urlencode from Python's standard
library. The difference is that Django version handles non-ASCII strings
correctly.
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
-~----------~----~----~----~------~----~------~--~---
