Decouple single vs. multiline widget choice from database storage type for CharField vs. TextField

[lalo.martins@…]

This patch makes the choice of limited vs. unlimited database storage (models.CharField vs. models.TextField) orthogonal to the choice of single vs. multiline widget (forms.TextField vs. forms.LargeTextField).

The fact that models.CharField used to use forms.TextField is an indication that something was wrong ;-)

For backwards compatibility, but much more importantly, because it's the reasonable thing to expect, the defaults are identical to the current behaviour. To get a multiline CharField, do: foo = CharField(maxlength=MAX_FOO, multiline_admin=True). Conversely, to get a single-line TextField: bar = TextField(multiline_admin=False). There -- now postgres users have no reason to use CharField anymore, unless there is a real and legitimate limit to the max size a value can have.

The argument multiline_admin was chosen to be consistant with radio_admin which is the only other similar argument I found.

Patch taken against magic-removal as of this post.

[lalo.martins@…]

maybe this shold also trigger a validator that a non-multiline field can't contain '\n'? I'm not sure it's in scope, so I didn't code it.

[Gary Wilson <gary.wilson@…>]

The newforms-admin changes will fix this by allowing to pass any widget you want. This is not worth changing and adding a new keyword argument right now.

[lalo.martins@…]

In fact, I would mark this "fixed" rather than "wontfix"; I believe newforms-admin does fix this feature request, in a way much more elegant and flexible than my patch.