#15667: Implement template-based widget rendering
---------------------------------------+--------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Milestone: 1.4 | Component: Forms
Version: | Severity: Normal
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by carljm):
Replying to [comment:16 brutasse]:
> > > - the MultiWidget class has a format_output() method that joins the
outputs from all of its widgets. The base MultiWidget just does
"".join(outputs) but in the admin (see !AdminSplitDateTimeWidget) it
inserts some markup between the outputs. I'm not sure of the best way to
move this to the templates... Remove format_output and make MutiWidget use
a higher-level template? Leave it as it is and let the users decide if
they want format_output to use the template system or string
interpolation?
> >
> > I think we should leave format_output() in place for backwards
compatibility, and have its default implementation render a MultiWidget
template. Moving forward, format_output can become an internal
implementation detail, and overriding the template becomes the documented
way to customize MultiWidget rendering.
>
> So a MultiWidget gets a template attribute? (it currently doesn't have
any). By default it'd be {{{ {% for output in rendered_widget %}{{ output
}}{% endfor %} }}}.
Yes, I that seems to me like the most consistent and flexible option.
> If it gets implemented like this I'd say format_output() can be
deprecated in favor of the API other widgets already have (get_context(),
etc), unless there is a use case for format_output() that can't be
implemented using a template. That'd be mostly for consistency if we want
a MultiWidget to have the same customization hooks as every other widget.
Yes, I agree that format_output could probably start a deprecation path.
It's a little bit tricky - what you actually want to deprecate is a user-
defined subclass relying on format_output being called. I'd need to take a
closer look at the code to see the best way to do this.
I'm looking forward to getting this in; Gregor's GSoC on form rendering
will depend on some of this (particularly the form template loader), and I
don't want to hold up his progress (if necessary we can just apply this
patch in his branch -- I'd rather do that than apply this to trunk before
it's ready -- but it would simplify things if we just had this in trunk).
If you have a latest-state-of-the-patch with some tasks remaining to be
done, let me know and I'll see if I can help.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:18>
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.
