Re: [Zope] dtml-var AND dtml-tree
Hi Dieter! Hi all others that commented! Thank you for reading and commenting. Actually, I first wanted to add a "urlparam_expr" to handle this parameter (consistent naming), and I looked at branches_expr... I didn't understand it: args['branches_expr']=VSEval.Eval(args['branches_expr'], expr_globals).eval Just copying this part (renaming branches_expr->urlparam_expr, of course) rendered to something like <method at ...> (probably very easy to solve, but - like with everything - not if you don't know) so I just took the shortcut with "md.getitem()" to get the parameter from namespace. Then again I thought "urlparam_expr" would no longer be a good name, since it doesn't accept expressions, hence the new name "urlparam_var"... As soon as somebody tells me how to solve this part (accept python expressions and evaluate them) I will put the patch in the Collector. In the meantime I *wanted to* wrap it up as some kind of "hotfix product", so no one has to mess with patching the python sources. Unfortunately... TreeDisplay's __init__.py - which in return calls TreeTag.py's Tree.__init__.py - gets called before my product's __init__, and I don't know how to override an __init__ (I think it's impossible, and it would make sense, too). Sorry. Any hints? Or is it really impossible? Thx for your comments, Danny
-----Ursprungliche Nachricht----- Von: Dieter Maurer [mailto:dieter@handshake.de] Gesendet: Freitag, 13. April 2001 06:16 An: Danny William Adair Betreff: Re: [Zope] dtml-var AND dtml-tree
Hi Danny,
Danny William Adair writes:
I patched "lib/python/TreeDisplay/TreeTag.py" so that I can have a parameter "urlparam_var", an object on the namespace that holds the querystring I want to insert. Thank you for the patch!
But, if you had called the parameter "urlparam_expr" and accepted a Python expression as value, then you would have been both more general and more consistent with the naming of other attributes, e.g. "branches_expr".
Then, after you patch is finished, you should put it into the Collector. It may have a chance to become part of Zope. Then, all users would be able to use it without the (tedious) necessity to repatch after each upgrade.
Dieter
Hi Danny! Danny William Adair writes:
.... As soon as somebody tells me how to solve this part (accept python expressions and evaluate them) I will put the patch in the Collector. Sorry, "branches_expr" was probably not the best example, I could have given.
Following is how it is done in "Products.MIMETools.MIMETag" for "type/type_expr": in "__init__": if has_key('type_expr'): if has_key('type'): raise ParseError, _tm('type and type_expr given', 'mime') args['type_expr']=VSEval.Eval(args['type_expr'], expr_globals) in "render": if has_key('type_expr'): t=a['type_expr'].eval(md) else: t=a['type'] Slight adjustments will be necessary in "TreeTag"....
meantime I *wanted to* wrap it up as some kind of "hotfix product", so no one has to mess with patching the python sources.
Unfortunately... TreeDisplay's __init__.py - which in return calls TreeTag.py's Tree.__init__.py - gets called before my product's __init__, and I don't know how to override an __init__ (I think it's impossible, and it would make sense, too). Sorry. Any hints? Or is it really impossible? You do not need to override the "__init__".
You override functions in the module or class. In your "__init__.py", you have: from TreeDisplay import TreeTag # now the module "TreeTag" is loaded # ready to be patched def module_func(...): .... TreeTag.module_func= module_func # overrides "module_func" in module # "TreeTag" def class_func(self,....): .... TreeTag.TreeTag.class_func= class_func # overrides "class_func" in class # "TreeTag.TreeTag" Dieter
participants (2)
-
Danny William Adair -
Dieter Maurer