Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #106 (closed defect: fixed)

Opened 14 years ago

Last modified 12 years ago

ability to set common attributes used for widgets

Reported by: kevin Owned by: anonymous
Priority: normal Milestone: 0.9
Component: TG Widgets Version:
Severity: normal Keywords:
Cc:

Description (last modified by kevin) (diff)

Standard widgets should all have the ability to set the relevant CSS classes for the various parts of the widget display, so that it's easy to integrate widgets with the user's style sheets.

Other common attributes need to be settable as well: id and accesskey.

Change History

comment:1 Changed 14 years ago by ianb@…

As an implementation suggestion, I think adding classes is generally more useful than replacing classes, especially as classes can get used for all sorts of things, including as a functional part of how the widget itself works. If you want to let people really force a style, allowing a style attribute to be given would be more specific.

comment:2 Changed 14 years ago by kevin

  • Description modified (diff)
  • Summary changed from ability to set CSS class used for widgets to ability to set common attributes used for widgets

comment:3 Changed 14 years ago by kevin

  • Description modified (diff)

comment:4 Changed 14 years ago by michele

I've put many toughts on this, but how do we get this right? I mean that this task should be left to the web designer so you shouldn't provide attributes on the widget instantation (controller side) but inside the template. This shouldn't be that hard for simpler widgets, but with complex widgets (like forms, datepicker) it will becomes quite hard and complex IMHO.

Maybe if people need custom accesskeys, id it's easier to just provide a different template for the widget.

I'm out of ideas.

See also: WidgetsBrainStorming

comment:5 Changed 14 years ago by michele

The only thing that comes to my mind is to setup a custom tag in the sitetemplate and use the py:match attribute so that web designers can easily set additional attributes for every element with a certain id directly from the template.

For example, if you have a form like this:

myform = TableForm(widgets=[
     widgets.TextField("name"),
     widgets.TextField("address")] 

on you template, if you really need some special attributes to be setted, you will simply do something like this (using the syntax i proposed on WidgetsBrainStorming):

<widget name="myform">

<attributes for="name" accesskey="n" onClick="cool_effect()" />

</widget>

Thinking more about it it's not that bad, quite flexible for customization purpose and easy to use for the designer, moreover it doesn't get on your way inside the controller and you don't need to prepare a custom template. The toolbox should make it quite easy if every widget lists it's default components and their id.

I also think that there should be a clear and strict guideline that every widget should adopt for naming conventions regarding id and class names, first of all a default "tg_" prefix (maybe customizable with a config option? let's say i want to use myapp_ inside my css stylesheet).

comment:6 Changed 14 years ago by michele

Forgotten to format the text, should be:

#text/html
<widget name="myform">
    <attributes for="name" accesskey="n" onClick="cool_effect()" />
</widget>

comment:7 Changed 13 years ago by michele

Aside from all my crackfull previous comments, does this make sense at all? Widget are quite complex, this means that usually they will not contain only a tag (for which setting some attributes makes sense) and in many cases they will contain even other widgets (like a form). IMHO we should aim to provide a "really" straightforward way of customizing the widget template.

For example a script that let's you do something like this:

tg-admin template widgets.TextField mytextfield.kid

comment:8 Changed 13 years ago by SuperJared <jared.kuolt@…>

  • Status changed from new to closed
  • Resolution set to fixed

This is mostly done. Other enhancements need to be taken care of but are much more complicated. (I like coffee)

Note: See TracTickets for help on using tickets.