There are currently 4 people (including myself) actively looking at
the widgets package. I've noticed a little variation in usage that I
wanted to get some consensus on.
Consider this case:
class TextArea(FormField, SimpleWidget):
template = """
<textarea xmlns:py="http://purl.org/kid/ns#";
name="${name}"
class="${field_class}"
id="${field_id}"
rows="${rows}"
cols="${cols}"
py:attrs="attrs"
py:content="value"
/>
"""
template_vars = ["rows", "cols"]
def __init__(self, rows=7, cols=50, **params):
super(TextArea, self).__init__(**params)
self.rows = rows
self.cols = cols
Before I get to my main point, I'd like to mention something I just
noticed: my preference is to have "name" be the first parameter. Like
this:
def __init__(self, name=None, rows=7, cols=50, **params):
super(TextArea, self).__init__(name, **params)
That way, widget users can always do this:
TableForm(widgets = [TextAreaField("foo")])
Is that a bad idea? It's easy to test for.
Now to my main point: the widget above is the way it looks after a
change I made. Previously, it didn't have the template_vars and had an
update_data that looked something like this:
attrs = d["attrs"]
d["rows"] = d[attrs].get(rows, self.rows)
d["cols"] = d[attrs].get(cols, self.cols)
My preference, as you can see above, is for attributes that are
specifically supported in the constructor to be explicitly contained
in the template (as they) and not rely on attrs. With the style that's
committed now, a user can do this:
tf = TextField(rows=5, cols=10)
tf.display(rows=8, cols=39)
or even
tf.display(attrs=dict(rows=10, cols=992))
So, this style is a bit less code (it leverages template_vars), it's
more explicit in the template and it still makes it easy (and
obvious!) for a user to override.
As always, though, I could be missing something, which is why I've
opened it up for discussion.
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
