On Tue, Feb 10, 2009 at 10:14 AM, Malcolm Tredinnick < malc...@pointy-stick.com> wrote:
> Your constraints are a bit arbitrary and, in fact, overly-restrictive. > In particular the "without changing ModelForm" wish is just that: a > hope, not something that falls out of the design as "it looks like this > must be possible." A ModelForm is a form that maps each model field to a > particular form field. That's all. It's not a prototype for arbitrary > model -> form mappings. Rather, it implements one particular sort of > (commonly useful) mapping. Indeed. And it also has special rules for foreign and m2m model fields. At the moment, for foreign key, model instance will be replaced with model id. And that's a bit restrictive. > I wouldn't be thinking about this from the widget level. Widgets are > just the rendering side. The better question is how to construct a form > class that allows you to specify form fields which can work with this > information. You're asking how to create a particular sort of form field > (Django-form field, not HTML-form field) here. The final rendering, via > Django-form widgets, will almost certainly just use normal (existing) > widgets. That's correct. I just want to have possibility for my custom form fields to participate in initial_data generation process (that's how ModelForm captures data from the model instance). Problem is in asymmetry: field which surely works only with models (ModelChoiceField/ModelMultipleChoiceField) is used to convert raw data (model id) to appropriate model instance, but not vice a versa. So I can create field that will "clean" raw data to model of my choice with some additional logic applied, but in order to do reverse conversion (from model to raw data) - I have to change ModelForm itself. That's what was bugging me :-) > I haven't worked out an answer, in terms of code, to your problem yet, > beyond thinking it didn't seem to hard. I'll try to find some time > tonight to work out some specifics and post tomorrow if nobody else > comes up with a passable solution. But, in the interests of > understanding the issue properly, I would suggest you spend a bit more > time thinking about this yourself, based on the lines I've written > above, rather than hoping somebody might give you the answer outright in > such a short space of time. > No need to, thank you. I know how to do it (by overriding default ModelForm behavior). It was more of the Thanks, Serge. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
