I don´t want to stress your help, but do you know where to find an example on using a custom manipulator for *updating* data.
question is, where does the custom manipulator gets the data (stored in the database) from. the way I did it so far: 1. using a changmanipulator to get and display the data 2. using a custom manipulator to handle the form, do validation and save the data when you´re saying that I should only use *one* manipulator, there has to be a possibility to get the data with the custom manipulator. something like: manipulator = UserProfile.MyCustomManipulator(user_id) sorry for being slow off the mark here, but that really contradicts my reading of the documentation. thanks again, patrick Am 21.09.2006 um 23:27 schrieb Ivan Sagalaev: > > patrickk wrote: >> well, now I´m totally confused. >> I though that´s exactly what custom manipulators are here for: >> "You can easily create your own custom manipulators for handling >> custom forms." (django documentation). > > All manipulators handle forms: > - prepare initial data > - validate data > - save data or redisplay the form with errors > > Automatic manipulators just know how to construct their fields > based on > model's fields. > >> that´s right. user_profile_manipulator doesn´t have that checkbox >> field. >> in the model, the relation is defined as: >> music = models.ManyToManyField(Music, blank=True, null=True, >> related_name='music') >> >> at this point, there is nothing defined about *how* to display that >> relation (e.g. using checkboxes). > > In fact there is a default representation for every Django data field. > For ManyToManyField it is SelectMultipleField. > >> as mentioned above, I thought that´s the primary use-case for custom >> manipulators: >> the custom manipulator handles the custom form >> the changemanipulator handles the data >> >> is that wrong? > > Yes. One manipulator is intended to handle one form entirely. You > need a > custom manipulator only if an automatic one doesn't work as you > want it. > >> some thoughts on that: >> 1. if I do it that way, I´m having checkboxes in the admin-interface, >> right? > > No. Admin code won't know anything about your manipulator and will use > automatic ChangeManipulator (with SelectMultiple for your 'music'). > > For completeness: to make it work in admin you could create a new > _model_ field as a subclass of ManyToManyField and make > CheckboxMultipleField its default manipulaator field class. > >> 2. is that the standard way to do it? it seems really complicated >> (ref. to finding and removing fields)? > > I wouldn't call it "standard" but for me it seems pretty > straightforward. I use it often and have convenience function for > removing fields by name. > >> 3. instead of "finding and removing a field" - why not write a custom >> manipulator, add specific validation etc.? > > You could. This is truly depend on the amount of differences between > automatic behavior and what you want. > > If you want a form that is mostly similar to an automatic one but with > some small bits changed then it makes sense to change automatic > behavior. Because if you create a custom manipulator you will need to > repeat all the definitions for all the fields that automatic > manipulators do based on model. And keep updating manipulator when you > change a model. > > But if your form is more custom and consists mostly of fields that > don't > belong to one model then it is more convenient to create a custom > manipulator from scratch. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
