Discussion on Ticket #16304

[j4nu5]

I have written a patch for ticket #16304 (https://
code.djangoproject.com/ticket/16304).

The ticket adds support for the HTML5 input placeholder attribute
(WHAT Working Group placeholder description -
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute),
in Forms as well as ModelForms.

I was wondering if a larger undertaking can be taken to make Django
HTML5 aware. Options may include support for new input types like tel,
email etc. which currently are rendered simply as text and ModelForms/
Forms have to manually override widgets to achieve desired results.

Comments please.

P.S. The submitted patch lacks tests. I could not figure out how to
write tests for the UI. If that is acceptable, can core devs please
accept the patch?

[Jj Del Carpio]

As much as I like the feature, I think that tying a presentation
widget (html5 specific) attribute to the Model definition is not
right. Just like the help_text attribute which should belong inside
forms and not models, or the old Admin innerclass. I agree that it is
very handy, but it does not belong to the Models. It also seems a bit
arbitrary to just go for Placeholder and why not for the title
attribute or any other that may become popular?. Start going by this
route opens a door for any HTML attribute we want be part of the
models on the Models.

Why not use the widgets dict on a modelform's meta [1] definition to
indicate you want a
forms.CharField(widget=forms.TextInput({'placeholder': 'fill me'})) -
or even pack a set of widgets or fields with easier syntax on an app?

I agree with d0ugal's comment on the ticket, that it should be part of
the form-rendering branch.

On a separate note, if this ended up being accepted, it would be
needed for any field that gets rendered by any HTML widget that
supports the placeholder attribute, like IntegerField (and friends),
Textfield, URLField, DecimalField, DateField, etc.

[1] https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overriding-the-default-field-types-or-widgets

On Feb 11, 12:13 pm, j4nu5 <sinha.kusha...@gmail.com> wrote:
> I have written a patch for ticket #16304 (https://
> code.djangoproject.com/ticket/16304).
>
> The ticket adds support for the HTML5 input placeholder attribute

> (WHAT Working Group placeholder description -http://www.whatwg.org/specs/web-apps/current-work/multipage/common-in...),

[Carl Meyer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 02/11/2012 10:13 AM, j4nu5 wrote:
> I have written a patch for ticket #16304 (https://
> code.djangoproject.com/ticket/16304).

Thanks for the patch.

> The ticket adds support for the HTML5 input placeholder attribute
> (WHAT Working Group placeholder description -
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute),
> in Forms as well as ModelForms.

I agree with the previous commenter that HTML widget attributes do not
belong in model field definitions. Making it possible to achieve
arbitrary modifications to ModelForm output HTML without ever overriding
a widget in the ModelForm is a bad design goal; there's a reason the
ModelForm (and widgets) exist as an intermediary layer.

> I was wondering if a larger undertaking can be taken to make Django
> HTML5 aware. Options may include support for new input types like tel,
> email etc. which currently are rendered simply as text and ModelForms/
> Forms have to manually override widgets to achieve desired results.

There is an existing ticket with patch to support HTML5 input types
(#16630). This is also addressed by the template-based-widgets patch in
#15667. I think the latter is the best direction, but it is blocked by
slowness of the template engine.

> P.S. The submitted patch lacks tests. I could not figure out how to
> write tests for the UI. If that is acceptable, can core devs please
> accept the patch?

Patches without tests won't be committed. There are many existing
examples of tests that test form rendering and HTML output; for
instance, most of the tests in regressiontests/forms/.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk84VFsACgkQ8W4rlRKtE2fqbgCfZF+38wR0kbsdLnQ2oM5JBfxn
E0UAoOlnRgDVRXmuEaVPU2WsOe3C74Jh
=yR2q
-----END PGP SIGNATURE-----

[Kushagra Sinha]

Thank you for your inputs. I have updated the patch. Will keep in mind to think a bit about the overall design before jumping headfirst and writing a patch.

There is an existing ticket with patch to support HTML5 input types
(#16630). This is also addressed by the template-based-widgets patch in
#15667. I think the latter is the best direction, but it is blocked by
slowness of the template engine.

Thanks for the links. Will see if I can contribute.

Patches without tests won't be committed. There are many existing
examples of tests that test form rendering and HTML output; for
instance, most of the tests in regressiontests/forms/.

I will keep that in mind. The updated patch has tests.

P.S. carljm: Can you please have a look at https://code.djangoproject.com/ticket/14394 Is the patch acceptable? (Disclaimer: I did not write it.) If not, how can I contribute?

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.