Hi Mikhail,
On 04/01/2011 05:09 PM, Mikhail Korobov wrote:
> Hi Carl and Gregor,
>
> On 2 апр, 01:17, Carl Meyer <c...@oddbird.net> wrote:
>>
>>> 3. The designers I worked with are often interested on adding custom css
>>> class
>>> or an attribute to a form field. Most of the time this is really a pain
>>> to
>>> do if you don't have control over the python form code. Imagine a
>>> reusable
>>> app that ships with urls, views, forms. To add a single class you would
>>> need to: (a) overwrite the predefined url because you want (b) to specify
>>> an additional parameter for the view which is (c) your custom subclass of
>>> the thirdparty form::
>>
>>> class ChangedAttributeForm(ThirdPartyForm):
>>> field = forms.CharField(max_length=50,
>>> widget=TextInput(attrs={'class': 'fancy-text-input'}))
>>
>>> btw: This also violates the DRY principle since you have to redefine the
>>> used field type, it's attributes (like ``max_length=50``) and the widget.
>>
>>> I want to tell the designer how he can do this without my help in the
>>> template.
>>
>> I agree with your Motivations section - in particular this final line,
>> which sums up the core motivation as I see it.
>>
>
> This goal can be achieved without changing django, see
> https://bitbucket.org/kmike/django-widget-tweaks
>
> Each widget is instantiated by field in 'as_widget' method now, and
> the field passes 'attrs' argument to widget with extra attributes.
>
> The idea behind django-widget-tweaks is simple: it provides template
> filters that take field instance and wrap its 'as_widget' bound method
> so it receives extra attributes (and pass these extra attributes to
> widget). This way widget attributes (including input types and css
> classes) can be altered in templates without touching python, e.g.:
>
> {{ myform.field|add_class:"fancy-text-input" }}
> {{ search_form.query|attr:"type:search" }}
>
> Implementation:
> https://bitbucket.org/kmike/django-widget-tweaks/src/0e9bac3c71bd/widget_tweaks/templatetags/widget_tweaks.py
That's quite a neat app - I have some similar template filters
implemented in some of my own projects. It doesn't cover the full range
of Gregor's proposal -- but I actually think most of Gregor's proposal
would be possible to implement outside Django. Perhaps we should
consider whether it would be preferable to start it off that way, or
focus the proposal more on where Django itself really needs to change.
Personally, I think HTML generation in Python code is a bug, and I'd
like to see it eradicated from Django, so I'm pretty open to seeing this
stuff make it to trunk.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
