On Tue, 2007-06-05 at 07:33 +0000, simonbun wrote: > I'm having some trouble solving a newforms problem that other people > must have run into as well. Feel free to share solutions or > workarounds if any. > > Let's say I have a RegistrationForm that is used for registering new > users. It has the usual 'name', 'email', ... etc fields. When a new > user registers, my custom 'clean_email' method is called that checks > if the entered email address is already in use. If it is, this user > has probably already registered, so i raise a validation exception. > All this works as expected for registering new users. > > Now I want to provide the possibility for registered users to change > their data. So I create the form instance, passing the user > object's .__dict__ as data (form_for_model is not a viable solution in > my case). The form is rendered with the correct data prefilled and the > user can edit his data. The problem however, is that the emailfield is > validated again, and the validationerror is raised saying that the > email address is already in use. This time around i would need a > different clean_email method.
I think you're trying to do the work at the wrong point in the process. If you want to use the same form object for creation and updating, the asertion that "email is unique" is not a property of your form. Don't check it in clean_email, because it isn't universally true. If you already have a way of differentiating between "new" and "existing", then make your main form class be the "existing" case (does not check email uniqueness) and then subclass it for "new" and all the subclass does is add the new clean_email() method. You "create a new person" view then instantiates the sub-classed version. All code is only written once; no repetition. If you want to use exactly the same for object and act differently based on whether this is a creation or an update, it sounds like you need to add an "is new" flag to the form. You may want to randomise and encrypt this slightly to avoid spoofing, but it would certainly work around your problem easily enough: have the is_new field early in the process, clean_is_new will decrypt and unscramble the value and then clean_email, which comes later, can use that value to decide how to validate. I think the first solution is probably the most straightforward, though both will work. > How do I solve this problem? I could create a subclass of my form that > overrides the clean_email method, but there must be a better way. Why do you assume this isn't a good way? Subclassing of classes is designed for *precisely* this type of use case: you want to override a small portion of the functionality. > What would solve my problem is bound newforms not validating when > rendered unless .is_valid was called or .errors was accessed in the > view. There's probably a downside to this approach that I'm not seeing > though. I don't like that idea. How can you hope to get away without validating your data in the long term, or giving the user feedback on their errors? You don't have to display the errors at rendering time if you don't want to, although it sounds a bit fragile. You can even dive in and modify Form._errors if you want to, but it doesn't seem necessary in this case. 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
