setting the css class of a widget (tg 1.x)

2 views
Skip to first unread message

Kane

unread,
Aug 21, 2008, 12:06:44 AM8/21/08
to TurboGears Trunk
There are some things that are insanely difficult to search for
because the relevant keywords are abundantly more common in a
different context (in this case "class")

I just wasted a huge pile of time trying to figure out how to set the
class of an old-style (non-tosca) widget. Google is not my friend
tonight. This message is a feeble effort to help anyone that happens
to be hunting for the same info in the future.

The answer:

css_classes=['yourClass'], options=[], attrs={}, validator= etc..

Yes, I tried attrs={"class": "yourClass"} but I'm building the widget
inside a KID template and nested ${yourwidget(blah=blarg,
attrs={}).display()} shatters. Yes I also tried
attrs=dict(class="yourClass") which also gives no love.

the keywords I tried (for the aforementioned feeble effort)
searching for "turbogears widgets id class", "SingleSelectField id
class", "SingleSelectField css class", 'turbogears cssclass' '"import
widgets" id'

reading the widgets documentation on turbogears.org gave me no love,
after finding the answer and doing a search "css_classes" is used but
not explained in just one place (not that it needs more than an
example) on the "Nicer Forms" RoughDocs.

Actually I blame html/css for the namespace collision. Sorry for the
rant, for various reasons this is both very rarely needed and silly
tricky to find.

Christopher Arndt

unread,
Aug 21, 2008, 8:44:13 AM8/21/08
to turbogea...@googlegroups.com
Kane schrieb:

> I just wasted a huge pile of time trying to figure out how to set the
> class of an old-style (non-tosca) widget.

> css_classes=['yourClass'], options=[], attrs={}, validator= etc..

The answer to what problem exactly is this? Can you give a bit more context?

> Yes, I tried attrs={"class": "yourClass"} but I'm building the widget
> inside a KID template and nested ${yourwidget(blah=blarg,
> attrs={}).display()} shatters.

That seems not a very common approach to me and (though I am on thin ice
here, without seeing more of you code) a violation of the MVC principle.
I would always define widgets in pure Python modules and pass them in
the controller or, if you must, import them in the template.

> Yes I also tried
> attrs=dict(class="yourClass") which also gives no love.

Yes, because "class" is a Python reserved keyword.

> reading the widgets documentation on turbogears.org gave me no love,
> after finding the answer and doing a search "css_classes" is used but
> not explained in just one place (not that it needs more than an
> example) on the "Nicer Forms" RoughDocs.

Can you please do as a favor an point us to the place where this used,
so we can add an explanation and example (can you provide one, maybe)?

Chris

Kane

unread,
Oct 19, 2008, 5:24:01 AM10/19/08
to TurboGears Trunk
(yes, I'm replying months later.)

The general problem was that there doesn't seem to be documentation
for the possible named parameters that widgets accept. Given the rate
of development within TG this is entirely understandable.

Specifically I wanted to override the class of my widgets for both css
cosmetics and javascript reasons. In one particular situation this is
difficult. I had shifted a lot more than a clean MVC should into the
templates because they can be modified without restarting the server
process. Not a good reason.

The one page on the turbogears site that uses css_classes is:

http://docs.turbogears.org/1.0/RoughDocs/NicerForms?highlight=(css_classes)
Reply all
Reply to author
Forward
0 new messages