On Fri, 2007-06-08 at 11:01 +0200, Przemyslaw Wegrzyn wrote: > Malcolm Tredinnick wrote: > > >>I have some CharField's in my model, I'm using create_update generic > >>views to edit them. I need all text data to be strip()'ed before being > >>saved to database. How can this be done in the most simple way? > >> > >> > > > >In the model's save() method. > > > > > Hmm, is there any way to do it before validation? > > If I send the user back to the form to correct some data, I'd like him > to see already stripped data. > > For the moment I use my custom 'generic view' instead of create_update, > and I'm passing optional 'preprocess_callable' to it if I want to do > anything like that. But I consider it a hack, it's far from being clean > solution.
I can't think of a way off the top of my head to do this with generic views. With a manually created (old)form, you could do this by sub-classing oldforms.TextField and putting a prepare() method in the sub-class that does the stripping, I guess, but then you are no longer using the generic view (which is not a bad thing). > >Not really; that is one of the points at which you should be thinking of > >writing your own views. Fortunately the problem will soon (for trunk > >users; in 1.0 for released version users) be moot as generic views are > >moved to use newforms rather than oldforms/manipulators. > > > > > That's what I did - I have my own (very simple) generic editor view. How > is this supposed to be done with newforms? The create/update process for newforms already exists, actually: look at form_for_model() and form_for_instance() in newforms. They allow you to create a form, populate it with existing data and save it back to the model with a built-in save() method. So you only need to wrap that in a simple view to create the form and return an HttpResponse, etc. Shouldn't be more than half a dozen or so lines, I would guess. Since you can also pass in a callable (to form_for_model()) that allows you to modify fields at will (as the form is created), you could intercept any of your fields that are going to be text fields, and return a Field subclass that does the stripping as part of the clean() method on the field. Alternatively (and this probably the better solution if you just have a few fields), look at writing clean_<fieldname>() methods that do the same thing. Either tonight or tomorrow I'll commit something like the documentation Joe Heck wrote about the various clean methods. In the meantime, you can read the patch in ticket #4473. Those docs look fairly reasonable. I would have probably written the same sort of thing (:-) ). Read it now, in all of it's unexpurgated glory, before Adrian takes his editor's blue pencil to it and removes all the jokes and penetrating social commentary. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
