On Thu, Nov 29, 2012 at 12:32 AM, JC Briar <jcbriar.walkab...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
