I realize the voting for 1.2 features has passed and that the collective
attention will be focused on that list, but I'm hoping to get a core
developer interested enough to look at potential implementations for this
and suggest improvements. The thread I'm resurrecting is this one:
http://groups.google.com/group/django-developers/browse_thread/thread/f9aae709a7fda689
.
Without further ado:
On Aug 20, 9:01 am, Russell Keith-Magee
wrote:
> On Sun, Aug 16, 2009 at 5:45 AM, mrts wrote:
>
> > At HTML level, a form is a set of fields that gets submitted when
> > a the form submit button is pressed.
>
> > However, this is not the case with model forms and inline formsets
> > (e.g. an admin page with inlines) -- inline formsets are
> > disparate from the model form.
>
> > This creates at least two problems:
> > 1) it's impossible to display inline formsets in between ordinary
> > form fields (although they may logically belong to a particular
> > fieldset and not to the end of the form),
>
> This is only true if you consider {{ form }} to be the only way to
> render a form. Remember - you can modify your template to render
> individual fields on a form. If you're looking for sophisticated
> layout options, you should be looking at customizing your template,
> not trying to turn Django's Form.as_ul into the One True Form
> Rendering Tool (tm).
I don't buy this. IMO, the real problem with keeping formsets and
forms separate is that developers really should handle forms with
inlines as a single unit, but can't. Consider the example of a
Business model that may have multiple PhoneNumbers, EmailAddresses,
etc:
class Business(models.Model):
owner = models.ForeignKey(User)
name = models.CharField(max_length=50)
address = models.CharField(max_length=100)
class EmailAddress(models.Model):
email = models.EmailField()
details = models.CharField(max_length=50)
business = models.ForeignKey(Business)
class PhoneNumber(models.Model):
number = PhoneNumberField()
details = models.CharField(max_length=50)
business = models.ForeignKey(Business)
In order to present this, I have to create, initialize, pass, and
display a BusinessForm - which Django makes very easy on its own. I
have to do the same with the formsets for EmailAddress and PhoneNumber
- not as easy. As if it weren't bad enough to handle them separately,
they also need to handled /differently/. My nice, encapsulated, atomic
form has been shattered into three parts and my URLConf, views, and
templates all have to deal with that now.
While {{ form }} should obviously not be the only way to render a
form, it should _always_ be an option. It doesn't stop anyone from
customizing templates for more sophisticated layouts. Getting the
example I gave up and running requires entirely customized views (or
separate pages) and far too deep an understanding of Django to be
possible for beginners. And it's annoying for everyone else.
> > 2) it's impossible to create nested (recursive) inlines.
>
> This is true, but not necessarily a bad thing. I'm willing to be
> convinced otherwise, but I'm yet to see a case where nested inlines
> would yield a positive user experience. Forms inside forms inside
> forms is a recipe for UI disaster.
In my experience this is a /very/ common use case - which is even used
in Django admin itself - that's being overlooked. If some developers
want to create awful UIs who are we to stop them? Other devs trying to
quickly prototype code or who just don't need prettier layouts hit
major roadblocks here. Django should easily handle the common cases,
not try to enforce good web design.
I've written a creaky hack to work around the issue in my own projects
but after seeing this thread I'm going to take a shot at implementing
FormSetField (or something like it) myself. If anyone has any code -
or more arguments for or against that haven't been covered - I'd love
to hear them before diving in.
John Debs
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
