On 1/17/06, Michele Cella <[EMAIL PROTECTED]> wrote:
>
> 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.
Ahh. I see what you're geting at. You're correct that something like
attrs makes no sense in a complex widget, but makes perfect sense in
what you're calling a TagWidget. Making a change like that can make it
clearer to people what kind of Widget they've got and what they can do
with it. As long as we don't get into huge amounts of multiple
inheritance and stuff like that, such a refactoring can make the code
a bit cleaner and clearer.
Kevin
