On Thu, Nov 29, 2012 at 12:32 AM, JC Briar <jcbriar.walkabout@gmail.com> wrote:
-- Option 1 doesn't hold much appeal, for all the reasons you mention.
Option 2 is a possibility, I suppose. Checking to see if password_reset_confirm returns an HttpRedirect is a possibility I hadn't considered.
Option 3 is intriguing. But this part has me scratching my head:Then, write a method that has the same prototype as the constructor for the form that the password_reset_confirm() method is expecting, but returns an instance of *your* form, bound with the current request.
Okay, how could this method create a form bound with the current request? How is the method getting its mitts on the current request? The method is being passed to password_reset_confirm via the URL dispatcher – that is, I would need to have code like the following in my urls.py:
url(r'^password/set/(?P<uidb36>\w+)/(?P<token>[-\w]+)',
'password_reset_confirm', {
'set_password_form': abracadabra_method,
}),
Where does abracadabra_method get the current request?
Sorry - I probably wasn't clear - option 3 is an extension of option 2. You exploit the fact that you can call a view, and provide a generated function as the argument:
def bind_form(request):
def create_form_instance(data):
return MyForm(request, data)
return create_form_instance
def my_password_reset_confirm(request):
return password_reset_confirm(request, set_password_form=bind_form(request))
Yours,
Russ Magee %-)
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment