Jason Chu wrote: > > I think template_vars is fine. When you put something into > template_vars, you're saying you want it available to the template. > That doesn't necessarily mean that you're going to use it in the > template. >
But as I said there are situation where you may want it available only at update_data and never use it in the template (and maybe even remove it from d), this leads to confusion IMHO since the template_vars name isn't enough generic and it doesn't enforce the strong relation it has with the way an user can interact with a widget to customize its behavior. widget_args or widget_params with Alberto's definition in mind is just more clear and easier to explain IMHO: "any argument you can override when subclassing, initializing and display". (instead of only template arguments) > > Isn't __ the pseudo-private variable syntax? Doing a quick test, it > looks like that rule only applies to references inside methods of a > class (unless they're existing __ named methods) ie. methods defined > (with def) and referenced as self.__foo__ work, but when you try to set > a self.__foo__ inside a method, it translates it to > self.__Classname_foo__. > > I think that's more confusing than I'd like. > > Does a Widget really only need those three methods to be a widget? > What about display and render? > >>> class Test(object): ... def __css__(self): ... print "css" ... def __js__(self): ... print "js" ... self.__css__() ... >>> test = Test() >>> test.__css__() css >>> test.__js__() js css >>> AFAIK the rule you're talking about is applied only for attributes with a double leading underscore but without a double final underscore, they are used to make an attribute almost private (just more difficult to access in reality by using a name mangling) but I've always seen it's use being discouraged. >>> class Test2(object): ... __hello = "hello" ... def say(self): ... print self.__hello ... >>> test2 = Test2() >>> test2.say() hello >>> test2.__hello Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'Test2' object has no attribute '__hello' >>> test2._Test2__hello 'hello' >>> Anyway what we are talking about here is (as Simon said) an informal protocol, think of it as the one (as I said) being used by python with iterables and other things. And yes a widgets just needs to define __javascript__ and __css__ (and __validate__ for a form) since those methods will not be used by the end-user but only by TG internals (controllers.py), display/render are meant to be used by the widget user but they should be easy (as they are) to use and if you're writing your own widget system you could for example use show or something other, no constraint on this is needed to be sure that the mechanism works, the concept is more generic since you can just return any object inside your dict and if this object has __css__ and __javascript__ they will work right. ;-) Ciao Michele --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk -~----------~----~----~----~------~----~------~--~---
