On 2/5/06, Max Ischenko <[EMAIL PROTECTED]> wrote: > > > It's not only for theadsafety but also to keep the logic outside of > > templates, just compare the new form template with the old one if you > > need an example. :-) > > Well, I don't think availability of 'widget' in template namespace is > the reason. > > Plus, as history teaches us, assuming a user is less competent then the > author and forcing particular behaviour upon him is no good. ;-)
I agree with this, in general. The argument could be made that the new "locking" behavior of widgets that prevents you from setting self.foo after you've started using a widget could be viewed as forcing behavior, but I view it more as preventing a bug. The availability of "widget" in the template namespace is different because that's getting more into good design vs. bad design, which is a more "slushy" (soft) topic. >From the standpoint of widget authoring, just dropping widget into the namespace is appealing: it's the least amount of work possible. However, from the standpoint of widget *users*, there is an advantage to explicitly listing out the variables from the widget that should be available: *all* variables that the widget uses and defines in the constructor can also be overridden at display() time. For consistency's sake, it's nice to think that people wouldn't have to play a guessing game about whether they can override something. > > To summarize: > > 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 I'm proposing something similar to what was suggested elsewhere in the thread: a class variable that lists the attributes that should be copied from the widget to the template. template_vars = ["headers", "collist", "getcol"] It's a little more typing than just having widget available, but it provides the ability to override. There would be a method that copies those over to the dict that is called from display()... so nothing else is required if you don't override display(). > 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. Granted with just "collist" you don't know if the value came from the widget, or from the template which called display(). But, there should only be a couple places that people need to check to figure out where the value they're seeing came from, and the override-per-request capability from display() overrides is important in a number of cases. Kevin
