On 16/05/16 15:10, Carl Meyer wrote:
On 05/15/2016 11:01 PM, Curtis Maloney wrote:
So this seems to leave us only part way to removing rendering decisions
from the form code -- your widgets can be templated, but your form code
still needs to decide which widgets...

Yep, one step at a time. With django-floppyforms templated widgets I've
used a template filter that allows switching a widget's template path in
the template that's rendering the form, placing more control into
templates. I think integrating something like that could make sense as a
next step.

Sniplates works by pulling {% blocks %} from a nominated template as widgets -- these are widgets in the "macro" sense, rather than specifically the form field sense.

It lets you load multiple widget templates, each in its own namespace.

(Since widgets are Python classes that control not only markup
generation but also data retrieval, control over widgets themselves
needs to remain in Python code. But the rendering template could be
given the option to customize the template used to render the widget.)

The way I handle this in sniplates is the {% form_field %} tag "explodes" all the relevant details from the BoundField into the context.

Since the field tag can select the widget set to use, as well as the specific widget template, and other context overrides, it puts pretty much all the rendering decisions into the template.


You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to