- Zope-Dev - Zope lists

"Overriding Products"
by Martijn Jacobs 18 Mar '05

18 Mar '05

Hello guys. I have a question regarding product importing in zope 2.7.x, as since zope 2.7 this part is way more flexible then it was before. I'd like to accomplish the next situation : - A Zope base installation has Product X installed in /lib/python/Products which I want to change or develop further - x instances of Zope use the produtc from this base install. - At one instance I want to test and develop, without breaking the other instances. - Copying the Product X folder to the <instance_home>/Products folder is not an option, as import conflict errors occure if you do not remove the product from the base installation. - Copying a local version in all 4 instances is a solution, but to manage that will cost alot of work, especially if you have alot of instances. - What I really want is that you can copy the Product X folder to the Products (or "CustomProducts" for example) of an zope instance, and that zope will figure out itself that it should import that version of the product instead of the copy in the base installation. 'Overriding' base products is the name you could give this situation. I tried alot myself, for example checking in the __init__.py if there is a copy of this product in <instance_home>/CustomProducts and then importing that product instead of my own, but I always get into trouble : AttributeError: 'module' object has no attribute '<Classname>' It doesn't have to work for all products, only for some of the products that we are developing ourselfs. We also have a different structure than normal products as following : Main Product - Sub product X - Sub product Y In the __init__.py of Main product we import and initialize the subproducts. The idea is to put one of those subproducts in a zope instance/CustomProducts folder for further development and that the other instances of zope still uses the base version of the subproduct. I hope you can help, thanks in advance for your time. Kind regards, -- Martijn Jacobs East Site | Postbus 642 | 6800 AP Arnhem t: +31 (0) 26 35 14 295 | f: +31 (0) 26 44 20 432 @: mart(a)eastsite.nl | w: www.eastsite.nl

3 2

Zope 2.8 + Five post-sprint status
by faassen＠infrae.com 18 Mar '05

18 Mar '05

Hey everybody, We're wrapping up here at a very pleasant and productive Zope 2/3/Five sprint here in Paris. We've accomplished quite a lot, and we'll let you hear what this is in more detail soon. We've spent a lot of time with Zope 2.8, integrating Zope X3.0 and Five into it. Our work is on two branches: The five-integration branch: svn://svn.zope.org/repos/main/Zope/branches/five-integration The trunk, which has synchups with Zope 2.7 fixes: svn://svn.zope.org/repos/main/Zope/trunk The Five integration branch contains Five, and a version of Zope X3.0 made for integration with Zope 2.8 (as a svn:external). We hope that this branch can be merged into mainline Zope 2.x trunk soon. I hereby want to thank everybody here at the sprint who worked so hard on this. It's really your work, guys, I just kept the todo list. :) Regards, Martijn

1 0

checkPermission and proxy roles
by Tim McLaughlin 16 Mar '05

16 Mar '05

Issue #'s 78, 846, 1125 all relate to checkPermission not considering proxy roles. #78 was resolved, however, from the looks of the code (and I haven't tested this), it will fail to Cut/Paste because the 'Delete objects' perm would be permitted by the proxy role which is not considered in the checkPermission. Anyway, the question is this... Why doesn't checkPermission consider proxy roles? I found the following discussion in Zope-CMF and it looks like this was "fixed" in CMF, but it seems to me like this should be the default policy behavior in Zope. We can do the patches if there's no reason for it being the way it is... Cheers, Tim ------------------------------------ begin quote Dieter Maurer wrote: > I think, we should have both possibilities: > > [1] check whether the real user would have the permission > (independent of proxy roles) > > [2] check whether the current context has the permission > (dependent on the current proxy roles and other > execution security aspects (such as ownership)) I'd like to replace utils._checkPermission in CMF HEAD with the attached code. This would change the behavior of _checkPermission from [1] to [2]. (If I didn't make a mistake.) The way utils._checkPermission is used in CMF implies possibility [2] would be the right behavior, the fact it implemented [1] looks like a bug to me. I don't know of any code that'll break if we switch to [2]. I can see there might be a need for [1]. But in this case you can use Zope's checkPermission method. If there are no objections I'll soon make a CVS checkin of the attached code. Cheers, Yuppie ----------------------------------- -- Tim McLaughlin Chief Technology Officer Siteworx, Inc. Innovative internet solutions. 703.964.0300 ext. 208

1 0

Re: [Zope3-dev] Re: Heads-up: Zope 2.8, Zope 3 and Five
by faassen＠infrae.com 16 Mar '05

16 Mar '05

On Tue, Mar 15, 2005 at 07:31:51PM +0100, Christian Heimes wrote: > Martijn Faassen wrote: > >[Could you point me to the issue or mail describing the old-style BTree > >problem? I may have run into it under another name or something.] > > http://zope.org/Collectors/Zope/1695 > > Persistent* were fixed yesterday by Tim Peters Thanks for the pointer. [snip] > That sounds a little bit better but Jim was worried for a long time to > add zope.interfaces and related. Just read the last discussion over > adding parts of ZopeX3 to Zope2.8. I was involved with the discussion. It actually turns out stitching in parts of Zope 3 is much much harder than stitching in all of it; the latter is just a distribution issue. > On the other hand we maybe get more developers from Five and ZopeX3 into > Zope2 because they want to use Zope 2.8. > > Let's see what the future will reveal us. Yes. And again, I totally understand where you're coming from. I'm coming from the same direction. Regards, Martijn

1 0

Odd behavior of undoable_transactions()
by Paul Winkler 16 Mar '05

16 Mar '05

Is anyone but me bothered by this behavior of undoable_transactions()? If I have a folder /foo and another folder /foobar, transactions for /foobar are displayed in foo.undoable_transactions(). This is clearly caused by lib/python/ZopeUndo/Prefix.py. The behavior matches the docstring - Prefix only cares if one string starts with the other, nothing more. But is that really desirable? Since this is intended purely for use in Zope, wouldn't it be more useful if it cared about paths as such? Something like (untested): class PathPrefix: """A PathPrefix() is equal to any path string it is a prefix of. Two prefixes can not be compared. """ __no_side_effects__ = 1 # what's this mean anyway? def __init__(self, path): path_as_list = path.split('/') self.length = len(path_as_list) self.path = path_as_list def __cmp__(self, o): other_path = o.split('/') rval = cmp(other[:self.length], self.path) return rval -- Paul Winkler http://www.slinkp.com

2 3

Re: [Zope3-dev] Re: Heads-up: Zope 2.8, Zope 3 and Five
by faassen＠infrae.com 15 Mar '05

15 Mar '05

On Tue, Mar 15, 2005 at 04:57:00PM +0100, Christian Heimes wrote: > I really *love* to have Five and parts of ZopeX3 in Zope2 but I don't > like how it is happening. Zope 2.8 is starting to stablize and still > contains some critical bugs like the incompatibility with old style > BTrees and you are going to add a heavy bunch of new features to it. [Could you point me to the issue or mail describing the old-style BTree problem? I may have run into it under another name or something.] > I would prefere this way: > > * Get Zope 2.8.0 out ASAP > > * Branch of Zope 2.9 from 2.8 when 2.8 is in rc phase. 2.9 should be > the target for ZopeX3 and Five only, no other features so you can get > 2.9 out some month afte 2.8.0. > > "Release often, release early and one step after another". You are going > to make the same ugly and bad mistake we made with Plone 2.0.0. :( I completely understand where you're coming from and I share the worries. Some things mitigate this problem: * integrating Five doesn't actually imply many significant changes to Zope 2.8; it'll just be its own product. * integrating zope 3 only means some integration in the build script for Zope 2. It's just a Python library otherwise. * we're separating the work on Zope 2.8 and Zope 2.8 + Five, so we can back out from this plan if we want to, later, and go the 2.8 and 2.9 route anyway. So, in effect, we're not actually *creating* any new features. We're also not doing any deep integration work (Five already has that work). The features already exist and we're just distributing them along with the standard Zope 2.8 distribution. We're not ambitious about new stuff at all. I hope that is somewhat different from the path Plone took for 2.0. Regards, Martijn

1 0

Heads-up: Zope 2.8, Zope 3 and Five
by Brian Lloyd 15 Mar '05

15 Mar '05

Hi all - At the Paris sprint, a plan was hatched to integrate Five into Zope 2.8, which Jim, Andreas and others responsible for release management have endorsed. This will hopefully actually help spur 2.8 to the finish line as well as begin to provide an upgrade path into the future for Zope 2 developers. What this will essentially mean for is that: - Five will ship in the core distribution with Zope 2.8 - A subset of the Zope X3.0 packages will ship in the core distribution ...so it will be possible to use a number of Zope 3 technologies and patterns in existing Zope 2 applications. The Five integration layer provides support for Zope 3 interfaces, Zope Configuration Markup Language (ZCML), adapters, views, utilities, schema-driven content, and Zope 3 add and edit forms. Note that the Five layer does *not* attempt provide a ZMI user interface for Zope 3 components. Zope 2.8+ will include the essential Zope 3 packages, so it will not be necessary to install Zope 3 separately. If you are interested, there is now a 'five-integration' branch in Z2 SVN where this work is going on. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

1 0

Problems with non-zope object attribute access
by Dario Lopez-Kästen 11 Mar '05

11 Mar '05

Hello, I have this serious show-stopper problem that I do not know how to get around, so any input is appreciated. I am building a Product that is basically a Zope interface to a set of non-Zope APIs to a directory system. In my product at one point I receive a list of (not zope-based) objects from a factory method in the API set. These objects all represent Persons with all necesary attributes and lazy DB lookup etc. Very neat. What is not so neat is that I have no means of zope-unpack them and display them in a ZPT. I have tried the following in my product class: def _zopify(self, o): # wrap object o in a an Acquisition.ImplicitAcquisitionWrapper # add __allow_access_to_unprotected_subobjects = 1 # Return o o.__allow_access_to_unprotected_subobjects = 1 return Acquisition.ImplicitAcquisitionWrapper(o, self) and in my product code I do this. plist = get_non_zope_person_object_list(...) return [self._zopify(person) for person in plist ] but I still get """ The container has no security assertions. Access to 'lname' of (Products.pdbapi.person.Person instance at 0x03449DA0) denied. """ errors when I try to access the attributes of a person object in the list. I am very reluctant to add zope-specific stuff to the set of APIs because they are used in several other places that are not Zope-specific. I also would like not to have to duplicate code existing in the API just to have it become Zope-friendly, so I am trying to find alternative paths here. Any help is appreciated. Thanks, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. "...and click? damn, I need to kill -9 Word again..." - b using macosx

2 3

How To Trap Event
by Arvind Sidhaye 09 Mar '05

09 Mar '05

Hi Fowwloing the code in DTML-Methode <INPUT TYPE=BUTTON OnClick="(CAREA(this.form))"> But I am not able to call CAREA which Script(python) Please help me. Thanks Arvind Sidhaye

2 1

February Bug Day Roundup
by Chris Withers 07 Mar '05

07 Mar '05

Hi All, Ug, looks like things went from bad to worse. January's bug day was very quiet, February's was totally dead. Not a single issue was dealt with on the bug day and #zope-dev was dead for the whole day. I'm going to take a break from running bugdays for a few months since I guess we're suffering from bug-day-overload... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0