First of all, I would like to thank everybody for your accurate and fast answers. I am working with a small group of developers, each in different places and working at different times. According to my past experience in java, this means "cvs" ^_^ I have some doubts about how to synchronize Zope development with cvs or subversion. Should I stop using the ZMI? Should I develop a Zope Product instead? Should I use fsdump instead of webdav to export from zope ? Should I use webdav when deploying back to Zope? This is my actual state-of-the-art about team management in Zope : We develop inside locally installed Zope Instances, using the ZMI. At the end of the day, we export the work done using webdav, and this works for DTML documents, DTML methods and ZSQL methods. After that, we commit inside the source code repository, using the update, diff and merge features to synchronize with other developers' work. We need to deploy to a Zope server in order to test the integration of developers' code, so I wrote a little PUT_factory to re-create the right objects, this is a snippet: elif ext == 'zsql': from Products.ZSQLMethods.SQL import SQL return SQL(name, '', 'daticonvegno', '' ,'') elif ext == 'dtml': from OFS.DTMLDocument import DTMLDocument return DTMLDocument( '', __name__=name ) elif ext == 'dtmm': from OFS.DTMLMethod import DTMLMethod return DTMLMethod( '', __name__=name ) elif major == 'text': from OFS.DTMLDocument import DTMLDocument return OFS.DTMLDocument.DTMLDocument( '', __name__=name ) As you can see, it uses extensions to understand the type of the file. This has some minor drawbacks : 1) you have to use extensions to make it work, otherwise you will have trouble at deploy-time 2) some additional parameters such as the connectionIds for ZSQLMethods must be auto-magically chosen by the PUT_factory 3) what about more complex objects, such as Plone, Archetypes or Openflow? should I map them all in the PUT_factory? Is this the "right way" to do things in Zope? Is there any native solution for Source Code Versioning and Team Management? How do other team solve this issue? Any advice is welcome! Thank you very much in advance, Luca
Luca Dall'Olio wrote:
According to my past experience in java, this means "cvs" ^_^
For the rest of us, it means svn ;-)
Should I stop using the ZMI?
Probably. At the very least, take advantage of the webdav you seem to have already got working and use a normal text editor for editing your scripts and templates!
Should I develop a Zope Product instead?
Probably ;-)
Should I use fsdump instead of webdav to export from zope ?
No..
Should I use webdav when deploying back to Zope?
Not unless you're doing all your editing via WebDAV...
We develop inside locally installed Zope Instances, using the ZMI.
Eep, at least get a text editor going over webdav so you don't have to use a browser to edit your scripts and methods!
At the end of the day, we export the work done using webdav, and this works for DTML documents, DTML methods and ZSQL methods.
Okay, stop using DTML documents and methods. Use python scripts and ZPT, please god! ;-)
After that, we commit inside the source code repository, using the update, diff and merge features to synchronize with other developers' work.
Odd...
We need to deploy to a Zope server in order to test the integration of developers' code, so I wrote a little PUT_factory to re-create the right objects, this is a snippet:
elif ext == 'zsql': from Products.ZSQLMethods.SQL import SQL return SQL(name, '', 'daticonvegno', '' ,'') elif ext == 'dtml': from OFS.DTMLDocument import DTMLDocument return DTMLDocument( '', __name__=name ) elif ext == 'dtmm': from OFS.DTMLMethod import DTMLMethod return DTMLMethod( '', __name__=name ) elif major == 'text': from OFS.DTMLDocument import DTMLDocument return OFS.DTMLDocument.DTMLDocument( '', __name__=name )
Fair enough...
1) you have to use extensions to make it work, otherwise you will have trouble at deploy-time
Yup, but extensions are pretty handy ;-)
2) some additional parameters such as the connectionIds for ZSQLMethods must be auto-magically chosen by the PUT_factory
Oh, yes, that's silly ;-)
3) what about more complex objects, such as Plone, Archetypes or Openflow? should I map them all in the PUT_factory?
Ah, so you're using Plohn. Well, then you should put all you code in Filesystem Directory Views, it'll make it all _much_ easier for you! You can then look to GenericSetup to handle all your workflow configs, etc...
Is this the "right way" to do things in Zope?
Nope, not given the products you're using...
Is there any native solution for Source Code Versioning and Team Management?
Not really, the "History" tab is as close as it gets... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
I have created some localfs directory. I can see files from filesystem and delete them from Zope, but I cannot upload them or modify text files from Zope, because I get the following error : Traceback (innermost last): * Module ZPublisher.Publish, line 113, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Products.LocalFS.LocalFS, line 3, in manage_edit * Module OFS.Image, line 449, in manage_edit * Module ZODB.Connection, line 853, in register ValueError: assigning to _p_jar is not supported Searching this in google, seems to me that this is somehow related to the lack of Zope OIDs for localfs objects, and I suspect changes in Zope
= 2.8 but I cannot get any further in the solution Is localfs still supported?
Zope has full access rights to the local directory, this is my configuration : Zope Version (Zope 2.9.0-, python 2.4.2, sunos5) Python Version 2.4.2 (#1, Oct 3 2005, 01:55:05) [GCC 3.3.2] System Platform sunos5 Thank you in advance, any hint is welcome! Luca
Luca Dall'Olio wrote at 2006-3-14 12:26 +0100:
I have created some localfs directory. I can see files from filesystem and delete them from Zope, but I cannot upload them or modify text files from Zope, because I get the following error :
Traceback (innermost last):
* Module ZPublisher.Publish, line 113, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Products.LocalFS.LocalFS, line 3, in manage_edit * Module OFS.Image, line 449, in manage_edit * Module ZODB.Connection, line 853, in register
ValueError: assigning to _p_jar is not supported
"LocalFS" should not touch persistency attributes at all. Almost surely, the wrapper used by "LocalFS" for a "File" is a bit too near "OFS.File" which was designed for ZODB storage (and not a filesystem proxy).
... Is localfs still supported?
"LocalFS" was always a third party product. The first author has "LocalFS" meanwhile abandoned. The latest adaptions to "LocalFS" where done by some "Andreas". Maybe, he is willing to continue to support "LocalFS". -- Dieter
participants (3)
-
Chris Withers -
Dieter Maurer -
Luca Dall'Olio