Kevin Dangoor wrote:
>
> > My ideal vision:
> >
> > Widget
> >    |__ TagWidget
> >             |__ FormField
> >
> > TagWidget is a widget whose output/template is just a single tag and
> > hence supports attributes using py:attrs.
>
> TagWidget really sounds like STAN or htmlgen. I don't think that wheel
> needs reinvention, and widgets are designed to encapsulate something
> more complex than just "<foo>Bar</foo>".
>

Ok, but Then we should just remove the following widgets?

TextField
Hidden
SubmitButton
ButtonField
ImageField
RadioButton
CheckBox
...

they all provide just <input />, but TG needs them. :-)

But, seriously.
My motivation behind a TagWidget is to provide a base class for all
those widget that you can customize by setting just some additional
standard HTML attributes.

Ex. size for a text input.

I think you can do this only for single tag widget, how can you pass a
dict to a Grid widget? where will this attrs dict be applied? to what
tag between the many that you can find inside a complex template?

That's the grid template:

<table id="${widget.name}" class="grid" cellpadding="0" cellspacing="1"
border="0">
  <thead py:if="widget.headers">
      <td py:for="head in widget.headers">
         ${head}
      </td>
  </thead>
  <tr py:for="i, row in enumerate(widget.rows)" class="${i%2 and 'odd'
or 'even'}">
    <td py:for="cell in row">
      ${cell}
    </td>
  </tr>
</table>

now, what happens if I do the following (dumb example)?

grid = widgets.Grid(..., attrs={align: center}

a bit unpredictable for a complex widget, even more for a compound
widget.

That's a why I think the attrs argument belongs only to a TagWidget
class.

Widgets like a Grid should provide additional arguments for
customization, but they are up to the widget writer good sense just
like standard HTML attributes were (are) up to who defined the HTML
spec.

A solution is to pass a complex nested attrs dictionary, with some
fancy keys that define where their attribute end up.
But I think that at this point the easier and cleaner solution is to
just customize the widget template for my needs and pass that to the
constructor, instead of figuring out how I should construct a strange
attrs dictionary and what key I should use to customize this and what
to customize that (and you can understand this only if you look at the
widget template anyway).

That's just my own opinion by the way.

Ciao
Michele

Reply via email to