"Max Ischenko" <[EMAIL PROTECTED]> writes:
1. I don't like been forced to write boilerplate code like this:
def update_data(self, d):
d['headers'] = self.headers
d['collist'] = self.collist
d['getcol'] = self.getcol
2. I think using "widget.collist" or "widget.headers" from within
template is clearer then simply "collist" or "headers". No need to
wonder where's particular variable come from. And less cluttering
going
on.
I agree that the boiler-plate code is unnecesary and ugly.
But Michele made a good point on this: it encourages coding logic at
the python side (at update_data) and just sending "placeholder-
fillers" and iterables (selectresults, option lists, etc..) to the
template... it's more MVCish.
On Feb 5, 2006, at 1:47 PM, Jorge Godoy wrote:
I'm not, yet, writing my own widgets -- I may do something like
that soon,
though -- but I agree with Max here. It looks more obvious to what
is being
used on the template and the update_data method seems
unnecessary... But
then, I'm new to all this web stuff and I don't know the
repercussions of this
change, though.
--
Jorge Godoy <[EMAIL PROTECTED]>
The update_data method *IS* needed. Without it we wouldn't be able to
override widget attributes at display time (which I think is
essential) or to pass new variables to the template for each render
(like passing a new css class for changing a textfield's background
color, etc).
It's what makes the new widgets thread-safer too: a new dictionary is
built at each render for the values needed for EACH request. And
gives more control of what actually is being sent to the template
(think of it as a "mini-controller" for a "mini-template" :)
I still think something must be done to reduce the boiler-plate code
though, maybe something like this:
def update_data(self, d):
self.update_data_from_self(d, ['headers', 'colist', 'getcol'])
...
It's still, boilerplate, but shorter...
this idea could even be factored out into the Widget class so it
does it implicitly on every update_data, something like:
class MyWidget(Widget):
update_template_with = ['headers', 'colist', 'getcol']
.....
the code handling this could be something like (at Widget.display():
d = {}
for attr in self.update_template_with: # or
self.__class__.update_template_with
d[attr] = getattr(self, attr, None)
self.update_data(kw)
return view.transform(kw, template=self.template)
This last approach would reduce the boilerplate while preserving the
all-goodness ;) of update_data.
If full qualification is preferred (a là widget.name) it shouldn't be
too difficult to implement either.
What I'm positive about is that the widget instance should NOT be
passed to the template, just to emphasize that the template variables
are updated at every render (plus all the, now diminished, thread-
safety issues).
Regards, Alberto
