Re: [Zope-dev] ZPT in Zope Products
Wyatt Anderson escribi: Hello All, I am trying to use ZPT within a Zope Product I am trying to build. I want to test the container type I am addding to to determine what action to take. The following though from Products.PageTemplates.PageTemplateFile import PageTemplateFile def manage_addMyContainerForm(self, REQUEST): pt = None if self.meta_type in [ContainerType1, ContainerType2]: pt = PageTemplateFile(zpt/addMyContainerForm, globals()) else: pt = PageTemplateFile(zpt/containerError, globals()) return pt.pt_render() This produces the following traceback in Zope: Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Products.MyContainer.MyContainer, line 17, in manage_addMyContainerForm Module Products.PageTemplates.PageTemplate, line 90, in pt_render - PageTemplateFile at containerError Module Products.PageTemplates.PageTemplateFile, line 73, in pt_getContext TypeError: 'str' object is not callable Ive checked out the code in PageTemplate.py and PageTemplateFile.py and cant figure out what is going on. The line in question is root = self.getPhysicalRoot() Is it possibly some security thing? My class is setDefaultAccess(allow) for now. Ive also tried simply return pt with no traceback but without the desired results as the object is returned. Thanks in advance, Wyatt Try return pt() Santi Camps ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZODB for Java?
Ian Beatty wrote: Greetings. Does anyone know of a good (stable, reliable, fast enough for production use in a web app) ZODB-equivalent for persisting Java objects? www.jdocentral.com Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty [EMAIL PROTECTED] Physics Education Researchvoice: 413.545.9483 Department of Physics fax: 413.545.4884 Univ. of Massachusetts AIM: (available upon request) Amherst, MA 01003-9337 USA http://umperg.physics.umass.edu/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Jim, let's make this telegraph style :) OK, here's another. What about renaming the Zope 3 zope package to z. +1 - It fits with the expansion of Zope: Z Object Publishing Environment. - It's short :) - *At this time* (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this now. +1 Other reasons I like z: - Less noise in imports +1 - Echos the circle z +0 (that's a marketing issue ;)) - The packages in z can be used for more than just Zope +2 - Emphasizes the more minimalist nature of Zope 3 relative to Zope 2 +2 Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and zope
+0, not a problem. -1 for renaming 'Zope'. I endorse the 'src/zope' idea. Stefan On Mittwoch, Apr 14, 2004, at 15:00 Europe/Vienna, Jim Fulton wrote: Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote: | - The packages in z can be used for more than just Zope | | +2 So, here's an idea: - Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore. I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*. So, what about this: zope.component zope.interfaces (?) zope.configuration zope.testing zope.schema (soon-to-be-dead?) - All move to 'ca.*' zope.app.* - Move down to 'zope'. This is pretty rough. Probably there are more stuff that should move to 'ca', and some stuff which should be grouped into packages, so that 'zope' doesn't get excessively broad. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Breadth-first search is the bulldozer of science. -- Randy Goebel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Sidnei da Silva wrote: On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote: | - The packages in z can be used for more than just Zope | | +2 So, here's an idea: - Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore. I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*. Great So, what about this: zope.component zope.interfaces (?) zope.configuration zope.testing zope.schema (soon-to-be-dead?) - All move to 'ca.*' Most of this has nothing to do with the component architecture. ca has nothing to do with zope. zope.app.* - Move down to 'zope'. This doesn't solve name-conflict the problem. Or maybe I don't understand what you are proposing. This is pretty rough. Probably there are more stuff that should move to 'ca', and some stuff which should be grouped into packages, so that 'zope' doesn't get excessively broad. I think the depth vs breadth balence we have now is about right. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote: | So, what about this: | | zope.component | zope.interfaces (?) | zope.configuration | zope.testing | zope.schema (soon-to-be-dead?) | | - All move to 'ca.*' | | Most of this has nothing to do with the component architecture. | | ca has nothing to do with zope. So that's the intention. If it has nothing to do with zope, why it should be prefixed with 'zope'? I may have been unlucky on trying to enumerate the packages. I was trying to figure out what kind of stuff would be useful in the context of zope2. Maybe you can enumerate what packages are part of the component architecture, and what packages would be used in zope2? I have a feeling that most stuff in zope.app would not be used in zope2, but I'm mostly surely wrong. | zope.app.* | | - Move down to 'zope'. | | This doesn't solve name-conflict the problem. Or maybe I don't understand | what you | are proposing. See above. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher The most important early product on the way to developing a good product is an imperfect version. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Sidnei da Silva wrote: On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote: | So, what about this: | | zope.component | zope.interfaces (?) | zope.configuration | zope.testing | zope.schema (soon-to-be-dead?) | | - All move to 'ca.*' | | Most of this has nothing to do with the component architecture. | | ca has nothing to do with zope. So that's the intention. If it has nothing to do with zope, why it should be prefixed with 'zope'? From the zope package README.txt: Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. The one subpackage that's not usable outside the application server is the app subpackage, zope.app, which *is* the application server. Sub-packages of zope.app are not usable outside of the application server. If there's something in zope.app you want to use elsewhere, let us know and we can talk about abstracting some of it up out of zope.app. I may have been unlucky on trying to enumerate the packages. I was trying to figure out what kind of stuff would be useful in the context of zope2. Potentially, all of them. Maybe you can enumerate what packages are part of the component architecture, zope.component and what packages would be used in zope2? All of them, eventually probably including zope.app. I have a feeling that most stuff in zope.app would not be used in zope2, but I'm mostly surely wrong. I think you are probably wrong. But we don't know for sure yet. | zope.app.* | | - Move down to 'zope'. | | This doesn't solve name-conflict the problem. Or maybe I don't understand | what you | are proposing. See above. I still don't see how having a different package named zope addresses the name conflict with Zope. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
From: Sidnei da Silva [EMAIL PROTECTED] - Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore. 'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of course that means that suddenly the component architecture is called z, but that's OK, isn't it? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote: From the zope package README.txt: Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. Speaking as someone who's tried to use zope subpackages outside of z3, there are practical problems with this. About 8 months ago, I tried to pull ZPT, et al out to use as a standalone version. I ended up having to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and zope.i18n. All make sense (especially since I wanted internationalized ZPT), but tracking all the dependencies were difficult. I tried to update all that again a few weeks ago and found that I also now needed zope.i18nmessageid and zope.schema. It looks like Fred's packaging work will help with the very tricky task of figuring out the dependencies and creating distutils packages for the desired stuff. I've also heard that zope.schema is going away and that the dependency on both zope.i18n and zope.i18nmessageid might not be necessary. But I'm still concerned that there will be creeping dependencies among more things inside the zope package, making it harder to use some of those technologies independently. E.g. there are several standalone ZPT implementations in the wild, but I happen to think z3's is the best and would like to see it adopted more widely in the Python world. Also, for a long time I've wanted to see z3's interfaces package be used outside Zope3, perhaps even being adopted as a standard library package eventually. I wonder if living inside the zope container package helps or hurts those prospects. I understand the desire to carve out a package namespace that z3 can reliably use without risk of collision with other packages. I still think that's less of a practical concern in the Python world so I'd opt for an approach that gets the non-Zope specific technologies into the most hands of Python programmers. -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Lennart Regebro wrote: From: Sidnei da Silva [EMAIL PROTECTED] - Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore. 'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of course that means that suddenly the component architecture is called z No, the component architecture is z.component. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Barry Warsaw wrote: On Thu, 2004-04-15 at 09:25, Jim Fulton wrote: From the zope package README.txt: Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. Speaking as someone who's tried to use zope subpackages outside of z3, there are practical problems with this. About 8 months ago, I tried to pull ZPT, et al out to use as a standalone version. I ended up having to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and zope.i18n. All make sense (especially since I wanted internationalized ZPT), but tracking all the dependencies were difficult. I tried to update all that again a few weeks ago and found that I also now needed zope.i18nmessageid and zope.schema. It looks like Fred's packaging work will help with the very tricky task of figuring out the dependencies and creating distutils packages for the desired stuff. Eactly. Freds work is going to adress this problem. (I'll restrain myself from going into a tirade about how important this is for Python. :) I've also heard that zope.schema is going away I thin it will eventually be merged into zope.interface. and that the dependency on both zope.i18n and zope.i18nmessageid might not be necessary. Right, maybe But I'm still concerned that there will be creeping dependencies among more things inside the zope package, making it harder to use some of those technologies independently. E.g. there are several standalone ZPT implementations in the wild, but I happen to think z3's is the best and would like to see it adopted more widely in the Python world. We're aware of this problem. That's why we've decoded to make the dependency data explicit (manually created) rather than implicit (automatically created). Each separately distributed package will have a DEPENDENCIES.cfg that is created by hand and that *constrains* dependencies on other packages. It makes explicit the intended dependencies. Dependencies not listed here are bugs. Adding depenencies to this file should be considered a big deal. Also, for a long time I've wanted to see z3's interfaces package be used outside Zope3, perhaps even being adopted as a standard library package eventually. I wonder if living inside the zope container package helps or hurts those prospects. Probably neither. I doubt that there will ever be a standard Python interface system. I'm not going to hold my breath. Guido argued for having Zope's interfaces be in s subpackage (or have a weird name) specifically to make it easier to add a standard interface package later, assuming that a standard package might not be exactly the same as Zope's. I understand the desire to carve out a package namespace that z3 can reliably use without risk of collision with other packages. I still think that's less of a practical concern in the Python world We've had colisions in the past. That's why we're being careful now. (BTW, I think it was a mistake to have top-level persistent and transaction packages. I think that will eventually come back to haunt us.) The only way to avoid collissions is to pick stupid names (zthis, zthat). I much prefer z.this to zthis. This assumes that we can make it easy to install z.this into z. so I'd opt for an approach that gets the non-Zope specific technologies into the most hands of Python programmers. I think that that's a different discussion. The safest thing to do for now is to continue using a container package. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 10:23, Jim Fulton wrote: Each separately distributed package will have a DEPENDENCIES.cfg that is created by hand and that *constrains* dependencies on other packages. It makes explicit the intended dependencies. Dependencies not listed here are bugs. Adding depenencies to this file should be considered a big deal. That's very comforting! I like that it forces developers to be deliberate when adding cross-subpackage dependencies. -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] ZPT in Zope Products
This does not work either. With this I get the following traceback: Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Products.MyContainer.MyContainer, line 17, in manage_addMyContainerForm Module Shared.DC.Scripts.Bindings, line 306, in __call__ Module Shared.DC.Scripts.Bindings, line 341, in _bindAndExec Module Shared.DC.Scripts.Bindings, line 1, in ? Module Shared.DC.Scripts.Bindings, line 286, in _getTraverseSubpath AttributeError: 'str' object has no attribute 'other' return pt works with incorrect results...displays PageTemplateFile at containerError return pt.document_src() works to the extent that it actually displays what's in the ZPT but does not render any of the TAL. return pt.pt_render() does not work causing the traceback from my original message. return pt() gives me the above traceback. Unfortunately I cannot find any good documentation on ZPT. I could give up and do my checking in the ZPT itself but this does not lead to reusability. BTW, using Zope 2.7. Anyone out there with an example of how they've used page templates in a product? Thanks, Wyatt -Original Message- From: Santi Camps [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 4:26 AM To: Wyatt Anderson Cc: [EMAIL PROTECTED] Subject: Re: [Zope-dev] ZPT in Zope Products Wyatt Anderson escribió: Hello All, I am trying to use ZPT within a Zope Product I am trying to build. I want to test the container type I am addding to to determine what action to take. The following though from Products.PageTemplates.PageTemplateFile import PageTemplateFile def manage_addMyContainerForm(self, REQUEST): pt = None if self.meta_type in [ContainerType1, ContainerType2]: pt = PageTemplateFile(zpt/addMyContainerForm, globals()) else: pt = PageTemplateFile(zpt/containerError, globals()) return pt.pt_render() This produces the following traceback in Zope: Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Products.MyContainer.MyContainer, line 17, in manage_addMyContainerForm Module Products.PageTemplates.PageTemplate, line 90, in pt_render - PageTemplateFile at containerError Module Products.PageTemplates.PageTemplateFile, line 73, in pt_getContext TypeError: 'str' object is not callable Ive checked out the code in PageTemplate.py and PageTemplateFile.py and cant figure out what is going on. The line in question is root = self.getPhysicalRoot() Is it possibly some security thing? My class is setDefaultAccess(allow) for now. Ive also tried simply return pt with no traceback but without the desired results as the object is returned. Thanks in advance, Wyatt Try return pt() Santi Camps ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPT in Zope Products
Hi Wyatt,
from Products.PageTemplates.PageTemplateFile import PageTemplateFile
def manage_addMyContainerForm(self, REQUEST):
pt = None
if self.meta_type in ['ContainerType1', 'ContainerType2']:
pt = PageTemplateFile('zpt/addMyContainerForm', globals())
else:
pt = PageTemplateFile('zpt/containerError', globals())
return pt.pt_render()
I guess the problem is that the page template file is called without
acquision context. Usually a page template file is a class attribute of
a class which knows about acquisition.
You could mange in the right context via
return pt.__of__(self).pt_render()
but I am not sure if this will fly.
Cheers,
Clemens
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 11:39, Casey Duncan wrote: Additionally (and Jim and I have discussed this amongst ourselves) I feel strongly that the dependancies should be enforced by tests. Good point. The dependancy tests might need to be separate from unittests because they would probably require an import hook or somesuch. Perhaps a tool like pychecker could be leveraged or extended to provide this service. At a minimum this test would need to be run before packaging a distribution, but ideally would happen more often. I wonder if some kind of doctest could be added to the __init__.py of the package that hooked __import__ and then attempted to import each module in the package, tracking the imports. Then complain about anything not defined in DEPENDENCIES.cfg (and hmm, what to do about standard library imports?). Yeah, maybe some kind of pychecker hook would be better. :/ -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Stephan Richter wrote: On Thursday 15 April 2004 11:39, Casey Duncan wrote: Additionally (and Jim and I have discussed this amongst ourselves) I feel strongly that the dependancies should be enforced by tests. That is, if you introduce and errant dependancy (by adding an import to a new package not in the stdlib or DEPENDANCIES.cfg) that it break a dependancy test. I think this can be easily done using the finddeps.py utility. I think the hard work of finding all the dependencies in the first place is done. Note that Zope can also have dependencies in its ZCML files (which is handled by finddeps.py). Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py http://cvs.zope.org/Zope3/utilities/importchecker.py which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thursday 15 April 2004 13:22, Martijn Faassen wrote: Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py http://cvs.zope.org/Zope3/utilities/importchecker.py which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. Fred has fixed that a while ago already (if I read the checkins correctly). :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev], [Zope-dev] More arguments for z (was Re: Zope and zope)
On Thursday 15 April 2004 10:23 am, Jim Fulton wrote: (BTW, I think it was a mistake to have top-level persistent and transaction packages. I think that will eventually come back to haunt us.) I won't disagree with this. ;-( The only way to avoid collissions is to pick stupid names (zthis, zthat). I much prefer z.this to zthis. This assumes that we can make it easy to install z.this into z. As long as z gets installed *at all* (before/after is not an issue), we can do this now. This is supported, if only by accident, by the current implementation of distutils. I think that that's a different discussion. The safest thing to do for now is to continue using a container package. I like this as well. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope3-dev], [Zope-dev] Import checking code
On Thursday 15 April 2004 13:22, Martijn Faassen wrote: Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py ... which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. I keep meaning to get back to you about this; sorry it's taken me so long. I wrote the tokenize-based code before I saw your importchecker.py code; I'd decided to go with the tokenize module instead of the compiler package since the later was poorly documented (IMHO). I've no really strong feeling about either approach being better. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. I'm not sure simply re-implementing one of the finddeps.py internal interfaces is the right thing to do; that's some incredibly cludgey code in Zope 3. There's a lot of confusion about what values are paths and which are module names, and that makes me very uncomfortable. If you'd like to replace the code that locates imports, feel free to do so. It may be that conciseness wins; the tokenize-based approach certainly ended up being more code than I'd expected initially. On Thursday 15 April 2004 01:21 pm, Stephan Richter wrote: Fred has fixed that a while ago already (if I read the checkins correctly). :-) No, Martijn's talking about something else... kinda. I imagine he had even stronger feelings about your initial implementation. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Stephan Richter wrote: On Thursday 15 April 2004 13:22, Martijn Faassen wrote: Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py http://cvs.zope.org/Zope3/utilities/importchecker.py which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. Fred has fixed that a while ago already (if I read the checkins correctly). :-) Well, perhaps I missed something. It changed to use the Python tokenizer, I think, if it wasn't doing this already. It doesn't use the compiler module, as importchecker does Anyway, I guess the tokenizer is fine too, and might even be faster for all I know, just seems an unfortunate duplication of work, plus I checked in importchecker for little reason. :) Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Thu, 15 Apr 2004 [EMAIL PROTECTED] wrote: What happens is you write a new serializer, notably write a custom serializer for an object type you've already been using for a while, using the default one ? (Presumably because you WANT to be able to access the contents from other tools) I think I noticed that somewhere in the .properties file there was a note of the class used for serializing ... Is there a way for a serialized instance to remember which serializer was used ? Or does everything break when I change the definition of a serializer (Old instances can no longer be read) ? Ape has a solution. Every object is stored with a classification. The classification (a dictionary of strings, stored in whatever format is chosen by apeconf.xml) has at least two keys: class_name and mapper_name. The mapper_name tells Ape which mapper was used to store the object, enabling Ape to reliably use the same mapper to load the object later. The class_name is used by mappers that work with multiple classes. When Ape stores a new state for an object previously loaded, it disregards the earlier choice of mapper. So, for example, lets say you've made a class called UltraPageTemplate, which subclasses ZopePageTemplate. If you store that using the default configuration, Ape won't try to guess how you meant to store it and will mostly just pickle it. The mapper_name will be anyfile. Later, you add to apeconf.xml a mapper that specifically serializes UltraPageTemplate objects, using the mapper_name Products.UltraPT.UltraPT.UltraPageTemplate. Ape will continue to load UltraPageTemplates stored using the anyfile mapper because the mapper_name supercedes the class_name when loading. However, when you store new UltraPageTemplates or update existing ones, Ape will use your new mapper, since the old choice of mapper is not consulted at save time. Therefore, to update all existing instances of UltraPageTemplate to use your new mapper, you only need to get ZODB to load all the existing instances and store them again unchanged. If your new mapper is complete, the old pickles will go away and people will be able to edit UltraPageTemplates outside Zope. Using strategies like this, Ape is trying to achieve a mode of development that doesn't require you to decide how to store objects at the same time you write classes. You start with ZODB, a radically simple, unintrusive storage layer, then you customize gradually with Ape. I think Ape is making good progress toward that goal. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
On Wed, 14 Apr 2004, Kapil Thangavelu wrote: although i wonder if there is some hand waving in progress here that i can't see. i guess my semantic notion of versions has been that of long lived transactions, and is there a better means of thinking of them? how do they play across with multiple mounted zodbs? what would something like merge mean in the context of a catalog? By my understanding, outside the storage, different versions are completely independent. You could even simulate multiple databases using versions. It is the storage that knows how to create new versions, merge versions, and prevent objects being used in a version from being changed. Mounted databases try to use the same version as the root connection. To merge a catalog, you could bring one of the stored catalogs to life within the storage and replay the sequence of transactions that occurred in the other catalog. This could be tricky, and opening a catalog within a ZEO server would make the ZEO server less stable. I think there might be other ways to look at it. One way to simplify would be to put catalogs in their own storage, separated from the content they index. That way, you could (ab)use the transaction machinery to abort or commit indexes as you see fit within the catalog conflict resolver. I've experimented with this before, and it seemed promising. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
