Sure, my bad, this is the example with form_business, a GFK, before /
after: https://gist.github.com/jpic/c6a16723db62f779848f
If we make it to encapsulate value_from_object / save_form_data
elsewhere than in the model field then it will allow form fields and
forms used in the admin to do more.
I'm trying to understand what you're trying to accomplish at a very basic
level. I'm not familiar with any of the third-party packages you mentioned.
How will the proposed changes in Django simplify them? In your second mail
you proposed a "form_business" kwarg with a "YourFormBusiness" argument
Thanks for the advice, I started trying moving form-related stuff from
FieldBase into a new ModelFormFieldBase class, and it turns out that
there's a lot more we could, or should, move than just
value_from_object and save_form_data.
Why not move out everything that couples the form field and the m
Your description is a bit abstract for me to understand. Could you put
together a before (how the code looks now) and after (how the code would
look with this feature) for an example use case?
On Monday, February 1, 2016 at 2:30:15 PM UTC-5, is_null wrote:
>
> Hi all,
>
> My understanding of th
Hi all,
My understanding of the design issue I'm facing was too approximative
at the time I opened this topic, sorry about that.
The way I understand it now, is that we have only 2 moving parts but 3 features:
- input validation in the form field,
- business logic in the model field,
- problem:
Hi all,
Many apps provide new related managers to extend your django models with.
For example, django-tagulous provides a TagField which abstracts an M2M
relation with the Tag model, django-gm2m provides a GM2MField which
abstracts an relation, django-taggit provides a TaggableManager which
abstra
