Alberto Valverde wrote:
> Hi Michele,
>
> On Aug 1, 2006, at 12:10 PM, Michele Cella wrote:
>
> >
> > Hi guys,
> >
> > what about totally changing the way variable providers works?
>
> Too drastic for 1.0, isn't it? ;)
Yep, definitely... :D
>
> >
> > My idea is to check for a special method inside the actual controller
> > that returns a dict of variables that will be injected inside the dict
> > returned by every method of that controller, this allows for great
> > flexibility combined with OOP.
> >
> > Let me make an example:
> >
> > class BlogController(Controller):
> >
> > def __variables__(self):
> > return dict(cool_widget=cool_widget)
> >
> > def list(self):
> > return dict(notes=notes)
> >
> > the save method will always return cool_widget and notes.
> >
> > If you need something on every page you can subclass Controller and
> > use
> > it in every controller instead of the original one, you can also mix
> > things as you need.
>
> Sounds like a good idea and will surely reduce lots of boiler-plate
> in controllers. However, I would make the __variables__ signature
> (self, d) where d is the dict being sent to the template to update it
> with new variables (a là update_params). This would make it easier to
> extend the controller's superclass IMO, something like:
>
> def __variables__(self, d):
> super(BlogController, self).__variables__(d)
> d.update(cool_widget=cool_widget)
>
Mmm, I think the invoked method should take the precedence among
__variables__ so no need to modify any dict, you can do what you've
described in this way:
def __variables__(self):
d = super(BlogController, self).__variables__(d)
d.update(cool_widget=cool_widget)
return d
or we can just pass an empty dict and update it like you have show?
> BTW, do we really need those underscores? Maybe call it
> "update_variables"?
>
Well, it seems I'm the only one who likes the double underscore
(remember __css__, __javascript__, __validate__ ...) but to me it just
feels more pythonic, it clearly states that the method is special and
that the framework will recognize it's presence and eventually use in
the right way (just like __eq__ in python...), it clearly states the
presence of that protocol and moreover it doesn't introduce possible
name conflicts with exposed methods... maybe variables is not the best
name in this particular case.
> We can still keep the good 'ol variable_providers untouched for
> backwards compatibility.
>
Yes, for sure. ;-)
> Could/should this make it into 0.9a9?
>
Dunno... :-/
Ciao
Michele
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
