I had this same dilemma also. I was trying to create my own custom
login view, but the current built-in login view still uses the
oldforms, while I'm in the process of converting to newforms. The
AuthenticationForm in Django has a hasCookiesEnabled() method that
requires to have access to the request, but the clean() method in
newforms doesn't seem to take arguments. My understanding of clean() is
that it is designed to do what I want, which is to simply add more
arbitrary criteria for validation. Unfortunately, I can't pass anything
to it.
My temporary hackish solution is this:
In the view, when creating a form instance, the data is normally the
POST data, which is a dictionary-like object. I basically created a new
dictionary with the POST data plus the request, and this gets passed to
the form.
data = request.POST.copy()
data['request'] = request
form = AuthenticationForm(data)
...so in the form's clean() method I can access what I need:
def clean(self):
request = self.clean_data.get('request')
...
This probably isn't the cleanest or best way to do this (you should
leave POST alone), but it seems to work for now until the newforms API
has a cleaner way of keeping all validation, saving, etc. in the form
itself, which is going to require some clean way to get the necessary
objects to the form.
I'm happy with the newforms API and the profile stuff so far. I'd been
struggling with the task of creating login and profile editing pages
where the user account is extended with arbitrary profile data, and
where I have more control over what is required for validation and
when. The old manipulators way was unusable for what I was doing, even
with workaround hacks. Newforms has at least made that stuff possible.
I'm looking forward to when it's considered stable.
(As a side note, the reason why I was trying to create a custom
login/logout in the first place was so that I could set timestamps for
current_login and previous_login attributes that I created for user
profiles. They set the beginning of the current login and time of the
beginning of the previous login. The built-in last_login attribute for
user accounts does not seem to be set automatically upon login, and
even then it sets the time to the beginning of the current login, not
the previous login. I wanted to be able to keep track of both previous
and current.)
Good luck!
serbaut wrote:
Creating field classes for validation makes sense but what if I need to
validate in a request context?
Say for example that I need to check permissions for request.user in
clean?
def clean(self, value):
if request.user.has_some_property() and value > 100:
raise forms.ValidationError, 'You are not allowed to go that high,
please enter a value below 100.'
return value
Another example would be if one field needs to be compared to another
field.
Checking in form.clean() disconnects the error from the field so thats
not good.
I just noticed that you can define clean_<field_name>() which may be
what I need. Btw, why is not the current cleaned value passed to that
method?
Joakim
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
