Model default modelform

113 views
Skip to first unread message

Jamesie Pic

unread,
Aug 20, 2018, 9:21:22 AM8/20/18
to django-d...@googlegroups.com
Hi all,

Currently when you want a model to be edited from a custom modelform, you need to make use of that new modelform manually in your create/update views and admin.

Would it be possible to add a new overridable method in the model to generate a default modelform ?

Then, default create/update views (including admin's) could detect if a model has such a method and call it to get the modelform instead of going through the default factory.

For example:

class YourModel(models.Model):
    def get_form_class(self):
        return YourModelForm

Thanks in advance for your feedback

Have a great day

--

James Bennett

unread,
Aug 20, 2018, 9:38:54 AM8/20/18
to django-d...@googlegroups.com
I'd be -1 on anything that encourages people to use ModelForm with all fields included by default; that's asking for mass-assignment security holes.

Adam Johnson

unread,
Aug 20, 2018, 10:08:25 AM8/20/18
to django-d...@googlegroups.com
Not sure that's what's being suggested here James?

But I'm -1 on this because it's adding more coupling between models and forms.

Also Jamesie, can't you just subclass in your ModelAdmin to replace get_form / View classes to replace get_form_class and achieve the same thing? As far as I understand the only thing your suggestion changes is that the forms used in views and admin can be changed at once, which is not necessarily desirable as both are intended for different users.

On Mon, 20 Aug 2018 at 15:38, James Bennett <ubern...@gmail.com> wrote:
I'd be -1 on anything that encourages people to use ModelForm with all fields included by default; that's asking for mass-assignment security holes.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg--AGfXz4uLtAbC0miGCrQE9M1o6_cbC114UULBVhOPJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

Jamesie Pic

unread,
Aug 24, 2018, 5:35:43 AM8/24/18
to django-d...@googlegroups.com
Thank for your feedback.

It's the eternal misunderstanding of django's pattern, confusion between table, and model, model is de factores what couples table and form, I've posted articles about it already. I call this the elephant in the room but if I'm the only one to see it it means it's my mistake.

Doesn't matter

Have a great day

Claude Paroz

unread,
Aug 25, 2018, 3:47:59 AM8/25/18
to Django developers (Contributions to Django itself)
Le vendredi 24 août 2018 11:35:43 UTC+2, Jamesie Pic a écrit :
Thank for your feedback.

It's the eternal misunderstanding of django's pattern, confusion between table, and model, model is de factores what couples table and form, I've posted articles about it already. I call this the elephant in the room but if I'm the only one to see it it means it's my mistake. 

It is not (your mistake). I understand your proposal as an extension of the Field.formfield() API to the model level. I already wished that functionality in several of my projects, to define some sort of canonical form used for some model throughout Django. However, the current formfield() API showed some weaknesses (didn't search, but I know there were discussion on this list about this). So the whole tying between models and forms would benefit for a large-scale refactoring, probably following some registration pattern. If I had unlimited time, that's something I would have tried to tackle.

Sorry, that doesn't help much.

Claude

Jamesie Pic

unread,
Aug 25, 2018, 9:08:59 AM8/25/18
to django-d...@googlegroups.com
Hi Claude,

Thanks for your feedback, it's a great idea to make modelform a callable registry instance or something.

In some project we're going to try to acheive this kind of coupling and work with Python components instead of templates for example:

status = CharField(components=dict(form=MyStatusField, table=MyStatusCell, card=MyStatusCard))

But this happens would happen in a router class, not directly in the model: then you could remove Field.formfield() method.

Have a great day
Reply all
Reply to author
Forward
0 new messages