RE: strategies for using external py packages
Thanks, Tres, for your quick reply. Might I ask a followup question (you may refer me to some existing docs as well, that'd be great) - In the past I've messed with simply having a Script (Python) that goes: from Products.MyProduct.mymodule import mymethod result = mymethod.dosomething() ...this is without having any kind of proper 'instance' of the Product in my Zope instance. It's worked, though a) it's kinda messy, and b) I've never really been able to determine if this exposes me to memory leak problems (so far so good) or has other negative impacts or risks. How do things differ between this 'lo-fi' approach, and that of explicitly instantiating the Product somewhere in my Zope tree as you suggested? Thanks again, Jim -----Original Message----- From: Tres Seaver [mailto:tseaver@zope.com] Sent: Friday, October 01, 2004 11:32 AM To: Jim Abramson Subject: Re: strategies for using external py packages Jim Abramson wrote:
Can anyone recommend a good resource, online docs, examples that specifically deal with methods/best practices/caveats for using external python code libs within Zope.
I have read the relevant chapters in Zope Book and done quite a bit of googling but can't seem to find detailed material on this. My situation involves, on the one hand, a sizeable 'instance space' application, and on the other, some python modules/packages that I need to teach the instance-space stuff to use. The instance app is too vast to realistically rewrite as a zope Product all in one shot - therefore I'm looking for a sane way to gradually add external functionality (and later, offload existing functionality from instance -> external). What I'm most interested in is a discussion of External Methods vs. Products as a means for doing this, memory and performance considerations, etc. The external code should know nothing about Zope, ZODB etc - so I suspect what I need to design is essentially some sort of proxy layer. (If this isn't specific enough I can happily elaborate.)
Write a simple Zope product which provides a "façade" object for your package; then add an instance of that object to your Zope, and have your templates / scripts use the external library through it. In a CMF / Plone application, such an object would be a "tool". Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Jim Abramson wrote:
Thanks, Tres, for your quick reply. Might I ask a followup question (you may refer me to some existing docs as well, that'd be great) -
In the past I've messed with simply having a Script (Python) that goes:
from Products.MyProduct.mymodule import mymethod result = mymethod.dosomething()
...this is without having any kind of proper 'instance' of the Product in my Zope instance. It's worked, though a) it's kinda messy, and b) I've never really been able to determine if this exposes me to memory leak problems (so far so good) or has other negative impacts or risks.
How do things differ between this 'lo-fi' approach, and that of explicitly instantiating the Product somewhere in my Zope tree as you suggested?
PythonScripts can't access stuff in modules without security assertions (which is a good thing). You could perhaps make such assertions yourself somewhere (e.g., in your own product):: from AccessControl import ModuleSecurityInfo security = ModuleSecurityInfo('my.exernal.package') security.declarePublic('know_safe_method') Adding the proxy object allows you to remap (if needed) APIs from the underlying library (e.g., to return values which play nice with ZPT) Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
participants (2)
-
Jim Abramson -
Tres Seaver