-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mikołaj,
Thanks for your work on contributing to Django! I am a bit skeptical about defining form fieldsets in Python code, as they have no effect on server-side interpretation or validation of form data, they are purely an HTML/presentational issue. I think that in general we should be moving form presentation entirely into templates rather than adding more presentation-related attributes into Python code. There's already work begun on this via a Google Summer of Code project (see #15667 and #16922); there are some barriers to overcome (particularly performance issues with the template engine), but I think it's still the right approach for the long term. And the more form-presentation controls we add in Python code, the more difficult this transition becomes (because we end up with two conflicting methods of defining a forms layout). However, I can see some justification for simple fieldset definitions in the form definition, as a high-level way to group fields. This can allow more flexibility in defining custom reusable form layouts (via templates) that depend on having such field groupings. And it's clear that others want this feature: I won't stand in the way of it if another core developer wants to champion its inclusion. However, I feel quite strongly that even if we add this, we should NOT add the additional "classes" and "fields in a row" features that you mention. Fieldsets themselves are defensible as logical "structure" of the form - these additional features are getting into the arena of trying to fully define HTML layout of a form in Python code, which I think is fundamentally the wrong approach, and makes it more difficult for non-Python-programmer template authors to work with Django forms. Why should forms be an exception to the general rule that HTML and presentation belong in templates? I see the admin as the exception here, rather than as a model for how the forms library should work. The admin's purpose is to create generic customizable CRUD screens for arbitrary models; this is necessarily going to involve defining the available axes of presentation customization, and making it easy to do those particular customizations. That's a very specific use case; it means trading off flexibility for convenience in very simple customizations. That's an appropriate tradeoff for the admin to make in building on top of django.forms; it's not an appropriate tradeoff for django.forms, IMO. In sum: +0 to fieldsets in Python code, -1 to classes and rows defined in Python code. Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7TwyAACgkQ8W4rlRKtE2eWiACgnT5afZXt7skGy66pIa4zDTrM kKkAoOoM/VIvJNPFMk0eaROh2DYT7/gv =SdfG -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
