Wow, alberto, you are going above and beyond on this one. I'm going to take your advice and keep it the way it is.
I changed my viewconfig so that the field settings get passed along, but I am going to keep getValue in sessionConfig requiring a super(). That seems ok to me. maybe I should change viewConfig back, but if you want to take a look at my code and give me some advice on it I will take what I can get. It seems like we are doing very similar things on a design level. Thanks again, chris On Dec 15, 5:37 pm, Alberto Valverde <[EMAIL PROTECTED]> wrote: > percious wrote: > > I am trying to simplify the way you create sprockets, because it seems > > a little complicated. I need some expert help with metaclasses. A > > little background. > > SessionConfig is where you get the data from the database given the > > input that comes in from the controller. You have to call the > > "getValue" function with a dictionary: What I would like is if each > > inherited version of SessionConfig would call it's parents getValue > > recursively so that the return dictionary could be built up without > > the developer having to explicitly call the parents getValue > > function. Here is the code, pay attention to the "ide like to get rid > > of the following line of code" comment. > > This is somewhat similar to what TW does with its "post_init" method. > The "magic" is implemented here [1]. Pay attention to the: > > bases = list(inspect.getmro(self.__class__)) > > line where the bases of the object's class are listed in > method-resolution-order and the: > > base.__dict__[pre_name](self, *args, **kw) > > where it makes sure that the function is only called if it was defined > in that class (and not a superclass). > > To implement what you said I would: > > 1) In the metaclass: get the "getValue" method that was declared in the > class being built , rename it to "_orig_get_value" and place a getValue > method there which: > > a) make a list of all the object's bases (like shown above) > b) iterate the list calling the "_orig_get_value" if it is declared in > the base *and only in that base* (so the method is not called because it > is inherited from a base because we'll then call it twice when we reach > that base as we iterate all bases). To make sure the method really > belongs in that base use the base.__dict__ trick above. > > 2) Prepare myself to explain all this magic this to every potential > frustrated user who might ask about it in the future ;) > > However, I'd like to ask if you really want to complicate your code as > much with all this un-intuitive/un-pythonic magic? If I were to rewrite > TW again I will probably do so to get rid of all this "cleverness" which > now doesn't seem clever to me anymore :/ Calling a superclass' method > cooperatively is something common and well understood and I wouldn't > trade this convention unless you have a very good reason for it (I'm not > trying to suggest that you haven't...). > > Alberto > > [1]http://trac.turbogears.org/browser/projects/ToscaWidgets/trunk/toscaw... --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
