#15667: Implement template-based widget rendering
------------------------------------+------------------------
Reporter: brutasse | Owner: brutasse
Status: new | Milestone: 1.4
Component: Forms | Version:
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
------------------------------------+------------------------
Comment (by carljm):
Replying to [comment:7 brutasse]:
> Right, so I have a patch but it's too large for Trac :). I'll be using a
github branch instead:
>
> https://github.com/brutasse/django/compare/15667-template-widgets
This looks great!
> * !ClearableFileInput no longer has its 'template_with_initial' and
'template_with_clear' arguments. This breaks a widget in the admin but I
haven't started the admin widget migration yet. The question is whether
this is supposed to be a public API or not.
They aren't arguments, just class attributes. And they are not documented
(I avoided documenting them specifically because I was hoping we could
soon get rid of them by moving to template-based widgets). It's probably
worth a note in the release notes in this patch for anyone who had a
subclass overriding them, but since they aren't documented I don't think
we need to provide the full deprecation path for them.
> * The !RadioSelect "renderer" API should be deprecated. I left it
unchanged (although I added !PendingDeprecationWarnings), it still works
but it's not doing any template-based rendering. The templates give us
enough flexibility so I'm in favor of starting its deprecation.
Agreed.
> * I added a template loader that is added to the list of loaders, this
way the templates are always available and they can be overridden in
project- or app-provided templates. Template caching works as expected,
the cached loader also caches the forms templates.
So I think this is the trickiest part here. I'm hesitant to introduce
another implicit coupling between conceptually-separate components of
Django, and it makes me cringe a bit that there's now no way to use the
Django template language without having this forms template loader added
automatically. That said, I don't have any other brilliant ideas for how
to make this "just work" transparently when people upgrade. Needs more
thought.
On a more minor note, I'm not a big fan of how you're finding the
forms_template_dir, relying on the relative filesystem location of
django/template/loaders/forms.py and django/forms. I think it might be
better to import the django.forms module and use its __file__ attribute?
> * I chose to explicitly add the input's "name" and "type" to the
template context instead of leaving it in the "attrs" dictionary. I like
it this way but I can put it back in the attrs if we decide to.
I prefer this as well; more explicit.
> * Topic documentation and widget reference (I'll make a draft but I
'''will''' need help here :)
I'm happy to help with this at some point.
> I'll keep reporting my progress here and will update my branch on
github. As always, comments welcome :)
Great work, thanks!
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:8>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
