Opened 12 years ago

Closed 12 years ago

#16959 closed Cleanup/optimization (invalid)

Enhanced MultiWidget rendering using a layout

Reported by: Miguel Araujo Owned by: nobody
Component: Forms Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hi,

I have worked on an enhacement of MultiWidget that easily lets you control the rendering of a subclass using a layout, it's called MultiWidgetLayout. You can find it here:
https://github.com/maraujop/django-MultiWidgetLayout

Cheers,
Miguel

Change History (2)

comment:1 by Andreas Pelme, 12 years ago

Thanks for the contribution!

Having a more flexible way to specify output from form fields is a long standing issue. Gregor Müllegger has been working on a GSoC project this year regarding revised form rendering, using templates and a set of new tags for flexible form layouts.

I am not a core developer, but I think this approach is too narrow and specific for a particular widget to be included in Django itself. Also, your widget puts the display logic in the Python code instead of a template, which is the opposite direction of the GSoC work. I suggest you keep it on github and make it available for pip/easy_install installation on PyPi so other people who are interested can try it out and use it! Custom widgets and fields can easily live outside of Django itself.

Here are some info about rendering forms via templates related to the GSoC project, if you are interested:

http://groups.google.com/group/django-developers/browse_thread/thread/8eb1f07bfd949ab7 (The original proposal)
https://github.com/gregmuellegger/django/tree/soc2011/form-rendering (The branch which contains the GSoC code)

If you search on the django-developers mailing list you will find more information and discussions about improving the state of form rendering.

comment:2 by Julien Phalip, 12 years ago

Resolution: invalid
Status: newclosed

I generally agree with andreas_pelme's assessment and recommendations. At this stage this proposal is a bit too vague and it would need to be discussed more extensively before it can materialize as a ticket. So I would recommend you to bring this up on the django-dev mailing list with a more detailed proposal, and perhaps reopen this ticket once the general direction has been fleshed out. Thanks again for your suggestion!

Note: See TracTickets for help on using tickets.
Back to Top