April 2004 - Zope-Dev

Patch for CMFActionIcons: make edit work if icon expr is empty
by Joachim Bauch 20 Apr '04

20 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, as it's possible to create an action icon with an empty icon expression, but this action icon can never be edited again (a KeyError is raised), I propose the attached patch against ActionIconsTool.py After applying this patch, you can edit the empty action icons. Greetings, Joachim - -- Joachim Bauch, struktur AG Download icoya OpenContent 1.3 for FREE! visit http://www.icoya.de/iOC4free <- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAhQOEvb5cTc087cURAtUzAJ9Ao39VsNjyDgR7pXY0AMlQPZ67zQCgzt4v By3VjMoZ1bp+a6LELYHNxSg= =nPyP -----END PGP SIGNATURE----- Index: ActionIconsTool.py =================================================================== RCS file: /cvs-repository/Products/CMFActionIcons/ActionIconsTool.py,v retrieving revision 1.2 diff -c -r1.2 ActionIconsTool.py *** ActionIconsTool.py 13 Jul 2003 01:55:30 -0000 1.2 --- ActionIconsTool.py 20 Apr 2004 10:58:02 -0000 *************** *** 185,191 **** security.declareProtected( View, 'queryActionIcon' ) def queryActionIcon( self, category, action_id ! , default=None, context=None ): """ Return an icon ID for the given action. --- 185,191 ---- security.declareProtected( View, 'queryActionIcon' ) def queryActionIcon( self, category, action_id ! , default=None, context=None, resolve_icon=1 ): """ Return an icon ID for the given action. *************** *** 195,201 **** TALES expressions. """ ai = self._lookup.get( ( category, action_id ) ) ! return ai and ai.getIconURL( context ) or default security.declareProtected( View, 'updateActionDicts' ) def updateActionDicts( self, categorized_actions, context=None ): --- 195,201 ---- TALES expressions. """ ai = self._lookup.get( ( category, action_id ) ) ! return ai and (not resolve_icon or ai.getIconURL( context )) or default security.declareProtected( View, 'updateActionDicts' ) def updateActionDicts( self, categorized_actions, context=None ): *************** *** 305,311 **** o Raise KeyError if an icon has not already been defined. """ ! if self.queryActionIcon( category, action_id ) is None: raise KeyError, 'No such definition!' icons = list( self._icons ) --- 305,311 ---- o Raise KeyError if an icon has not already been defined. """ ! if self.queryActionIcon( category, action_id, resolve_icon=0 ) is None: raise KeyError, 'No such definition!' icons = list( self._icons )

2 1

Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for "z" (was Re: Zope and zope)
by Stephan Richter 20 Apr '04

20 Apr '04

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). Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training

3 7

Refernecing a zope page template's id ad title from a python script.
by altkey 20 Apr '04

20 Apr '04

Hi, I have a breadcrumbs python filesystem script. It's a long script that constructs dictionaries and places them in a list for a master_template to display. The dictionaries look like this relative = context.portal_url.getRelativeContentPath(context) .... code for various things ... ordinaryUrl = portal_url + '/' + join (relative, '/') ordinaryId = relative[-1] ordinaryD = { 'id' : ordinaryId , 'title' : obj.title_or_id() , 'url' : ordinaryUrl} In some cases I need to get an id for a zope page template instead of for 'context'. Can anybody tell me how to do that, or better yet tell me where the way to do it is documented? I haven't had much luck searching the source code for something that'll help. cheers, Phil

1 0

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 19 Apr '04

19 Apr '04

Kapil, Right now, the svn transactions are entirely contained within a single fileops operation: for example a "mkdir" connects to a transaction root, performs the necessary operations, and commits, all in one shot. Last night I took some more time to try and learn more about Ape's functionning (Where events come from, which interfaces are used for what, and TPC), so I'm starting to understand more ... The more I learn, the more I think closer integration between SVN txn's and Ape's TPC would be a good place to start before looking at adding features like history support and so on: defining a model for what happens in svn for each TPC related call (connect, vote, finish), and then as Shane had said, look at IFSReader/IFSWriter (Which I now call ISubversionReader/ISubversionWriter :P) to match. Right now the fs implementation stores "script commands" that are cummulated upon connect() (I think?), validated as best as possible upon vote() and run upon finish(). I don't see why this couldn't be adapted to SVN txn's ... connect() = start a txn, vote() = validation (what this entails needs to be defined, could involve delta operations, revision number matching, etc ... ?), finish() = commit the svn txn. Because we're within an svn transaction, there would be no need for fs style script command accumulation however, which is nice. J.F. -----Original Message----- From: zope-dev-bounces(a)zope.org [mailto:zope-dev-bounces@zope.org]On Behalf Of Kapil Thangavelu Sent: April 14, 2004 6:59 AM To: Shane Hathaway Cc: Jean-Francois.Doyon(a)ccrs.nrcan.gc.ca; zope-dev(a)zope.org Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote: > On Tue, 13 Apr 2004, Kapil Thangavelu wrote: > > > since > > objects modified in a version are in essence locked from participating > > in other transactions, actions like modifying content in a version in a > > cmf site amounts to locking the catalog from changes outside of the > > version, which amounts to shutting down write activities to a cmf site. > > This is only true of FileStorage. Some other storage could implement ZODB > versions with merging capability rather than locking. > good point, just because hasn't been doesn't mean it can't ;-) 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? > > i'm also curious how you dealt with svn transactions as part of the ape > > integration work to date. > > The same way it tries to impose transactions on the filesystem: in the > vote phase, Ape looks for possible problems and aborts early if it detects > anything that will cause the transaction to fail. Obviously, this > provides no guarantee, but covers many cases. > i was more curious how jean-francois was doing the svn ops in fileops, as svn is fundamentally a transactional store (as opposed to the fs), ie is there some record boundary notion of ape signalling the end of serialization for an object set, or was each operation being conducted in a separate svn transaction. -kapil _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org 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 )

3 5

RFC: A proposal for ZODB schema migration in Zope 3
by Jim Fulton 19 Apr '04

19 Apr '04

I've posted a proposal: http://dev.zope.org/Zope3/DatabaseGenerations for a framework for managing the migration of application/database schemas in ZODB databases in an orderly manner. The proposal is to apply this new framework in Zope 3, however, if it works well, it would be applicable to Zope 2 and other ZODB applications. Comments are welcome. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 3

Zope and zope
by Jim Fulton 18 Apr '04

18 Apr '04

Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for: - The Zope software - Instance (site) specific packages So adding two directories, rather than one for the Zope software isn't a big deal. Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

18 45

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 18 Apr '04

18 Apr '04

Oooooh, a very good idea indeed! We'll have to look at that eventually. The mechanism you describe is preferable, but it should be noted that subversion properties are easily accessible using the clients. So long as said properties are human readable/writable, that's also an option. The main issue for me (And many others I suppose), is the fact that every single object type I use is either completely custom, or a monkey patched version of a built-in type (Notably OFS.Image for instance). So there would have to be a reliable serializer for "other" objects, which I beleive you already have, so that's OK :) 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) ? J.F. -----Original Message----- From: zope-dev-bounces(a)zope.org To: Jean-Francois.Doyon(a)ccrs.nrcan.gc.ca Cc: hazmat(a)objectrealms.net; zope-dev(a)zope.org Sent: 14/04/2004 7:39 PM Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Wed, 14 Apr 2004 Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > Fact is if one wanted a client to interact with a svn repository that stores > zope objects, it would need to be fairly specifically designed for it ... > How would a client (Say dreamweaver with a subversion plug-in) know that > when editing an image, the x and y size properties need to be updated ? What > if someone monkey patches the image type to add some other > property/attribute ? I would say Ape is quite good at accepting data from non-Zope-aware tools, and I'd like to make it better. The fact that Ape stores the image dimensions separately from the image content is an implementation decision in the serializer. You could instead tell the serializer to detect image dimensions when loading the object. The detection is a relatively inexpensive operation. Shane _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org 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 )

3 2

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 18 Apr '04

18 Apr '04

The property schema thing is a good point, though I'm not sure we could ever do anything about it, not with the purpose to help "naive gui" clients work better with the repository. By nature the object structure (Class instance) is not fixed, so the amount/name/data of properties could vary arbitrarily. This is after all the major benefit of an OODBMS. Fact is if one wanted a client to interact with a svn repository that stores zope objects, it would need to be fairly specifically designed for it ... How would a client (Say dreamweaver with a subversion plug-in) know that when editing an image, the x and y size properties need to be updated ? What if someone monkey patches the image type to add some other property/attribute ? All we could hope to do is find a consistent and predictable way to handle properties, so that clients would know at the very least how to read/write them, but not necessarily know which one does what. I suppose there's possible ways around that actually, by providing some way to describe properties and what they do and so on ... but that's beyond the scope of what I'm trying to do I think ... J.F. -----Original Message----- From: Kapil Thangavelu [mailto:hazmat@objectrealms.net] Sent: April 14, 2004 6:51 AM To: Shane Hathaway Cc: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca; zope-dev(a)zope.org Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote: > On Tue, 13 Apr 2004 Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > > > Thanks for the extra tips, I'll check out those interfaces! I'm also getting > > up to speed on the whole mapper concept, where the work regarding properties > > handling seems to be ? > > Ape supports both annotations and Zope properties. Annotations are blocks > of multi-line text, while Zope properties are less constrained. On the > filesystem, Ape stores many Zope properties together in a single > annotation called "properties". Other annotations include object > classification, the remainder pickle (encoded in base 64), and security > information. > > What are the expectations and limits of Subversion properties? If they > are blocks of multi-line text, you can store the annotations as Subversion > properties. If not, we'll still need a .properties file. (Note that > the name ".properties" is thus confusing. Oops.) > svn supports aribtrary property values. ie you can store binary (remainder pickles, object classification, etc.) of arbitrary size on them. there is some question of how well some naive gui client will do when trying to list such properties, as there is currently no notion of metaproperties/property schema beyond the property namespace for introspection of a property. -kapil

3 2

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 18 Apr '04

18 Apr '04

Shane, As Kapil already mentionned, svn's support for properties is quite flexible, so that doesn't worry me too much. I would imagine and administrator having the flexibility of choosing how objects get translateds to files might be handy. My initial, uneducated thoughts on the topic were simplistic, but then I'm a big K.I.S.S. fan: simply pickle the entire object back and forth as one entity. This means for each object, there is one file on the fs. The benefit is greater simplicity ... the downside is that you couldn't check those files out of subversion and interact with them. I also have to imagine the former is faster ? But if usnig the latter, then I'd think that in SVN there would be only 1 file, written by a specific mapper for a specific content type, say image. the data written to the file is such that if checked out, the file "works", so I can open it in photoshop or something. I however, would simply put everything else in properties, if that makes sense at all. Zope properties, security information, and so on. 1 porperty, 1 piece of data. No need for reading/writing multi-line text. The only thing I'm not so sure about is this "remainder" ... Though if it really is a base64 encoded string, there's no reason not to put that in a property as well. The benefits I see: - The filesystem reflects the object structure, no extra files lying around. - a more consistent way to setup mappers/gateways: there's "data", and there's everything else. Have a common/defined/smart way of handling "everything else". - with the use of the properties related svn funtions, we better leverage SVN's features. - possibly better performance/simpler code by not needing the whole multiple file management and read/write of text files. Heck the whole AnnotatedFileSystem, thing could be dropped/replaced with a PropertyFileSystem implementation of some kind maybe ?? What do you think ? J.F. -----Original Message----- From: Shane Hathaway [mailto:shane@zope.com] Sent: April 13, 2004 10:46 PM To: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca Cc: zope-dev(a)zope.org Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 13 Apr 2004 Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > Thanks for the extra tips, I'll check out those interfaces! I'm also getting > up to speed on the whole mapper concept, where the work regarding properties > handling seems to be ? Ape supports both annotations and Zope properties. Annotations are blocks of multi-line text, while Zope properties are less constrained. On the filesystem, Ape stores many Zope properties together in a single annotation called "properties". Other annotations include object classification, the remainder pickle (encoded in base 64), and security information. What are the expectations and limits of Subversion properties? If they are blocks of multi-line text, you can store the annotations as Subversion properties. If not, we'll still need a .properties file. (Note that the name ".properties" is thus confusing. Oops.) > As for the seperation of code ... I now have a "subversion" directory as a > sibbling to "fs" ... I had to edit a couple of files outside that directory, > but still the seperation is nicer. > > eventually I'd have to make it into a product, is that doable ? Why not add your code to Ape? I think it would be easier for both of us to maintain that way. Shane

3 2

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 18 Apr '04

18 Apr '04

Well there you go, perfect :) -----Original Message----- From: Kapil Thangavelu [mailto:hazmat@objectrealms.net] Sent: April 14, 2004 6:49 AM To: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca Cc: zope-dev(a)zope.org Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?) On Tue, 2004-04-13 at 20:53, Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > Hello, > > Hmmm, well it's as stable as Ape and Subversion are respectively :) > > I wouldn't call it stable no, it's something I did over the long week-end we > just had, and that's about it :) > > Ape is at 0.8 and therefore becoming quite mature, I'd have to let others > speak as to it stability however ... > > Subversion is also probably quite stable (It just reached 1.0), though I > don't know how heavily tested it's been in a long running process (Might it > have some memeory leaks ?) ... the svn apache server model is a long running process and is fairly stable on memory usage. the python bindings require doing some manual memory management, but the pool api makes it easy to deallocate arbitrary allocations safely. the cmfsvnbrowser code i ref'd early has been in production by myself and others for almost a year and runs with a stable memory footprint. -kapil

3 2