morto-@dennisinter.com (damian morton) wrote:
Would using versions to 'archive' past issues be a bad use of versions? Is this actually possible?
In my opinion, Zope's versioning device is not suitable for 'archiving' past issues. Zope's versioning device is more for a team of programmers/content-managers working together. It is dangerous to use it to keep past issues, because someone might hit the commit button accidentally and then the old version is gone.
Is there a way to create a partial version, for example one restricted to a part of a tree?
Zope's versioning device is OK for this purpose. It does not actually limit the user to version a branch of the tree, but in practice a good discipline usually means the versioning device affects only a branch of the hierarchy tree.
Is there a way to create a version within a version?
No, Zope's versioning device is not good for this.
Where multiple people are working on a site, is it best for each person to be working in their own version, or is it best for each section of a site to have its own version, or should their be one version which everyone works in? Whats the best way to leverage the facility of having multiple versions?
My opinion for your site is this: your site is content-intensive. So, I would suggest you keep contents in local file system instead of keep them inside Zope's ZODB. The directory structure should reflect the release date structure of your magazine. In my own experience, Zope's versioning device is for multiple programmers to work on their own piece of code, without making the system unstable and thus affecting other programmers that are working on some other part of the system. So, in practice, you will have several versioning devices active at the same time. Versioning device also allows programmers to see what files are being worked on by what people. This way, you don't need to worry two people working on the same file and destroying each other's changes. In your case, you can still use the above scheme. But if we are talking about preparing the next issue of the on-line magazine, I would suggest this: (1) Create a folder for the next issue you will be working on. (This does not need to be the whole magazine, it could be just one part of the magazine. You create as many folders as you deem necessary.) (2) Use Zope's user management and create user/password for the folder, so outsiders won't be able to see the new version. Or you can use cookies or other devices to make the new issue invisible to outsiders. (3) Have a page containing index_html that does something like the following: <dtml-if "REQUEST.has_key('AlanWorkingOnMarchEdition')"> <dtml-call "RESPONSE.redirect(MarchEdition.absolute_url())"> <dtml-else> <dtml-call "RESPONSE.redirect(FebruaryEdition.absolute_url())"> </dtml-if> If you want to keep a permanent archive of past issues, you have to implement a lot of indirections inside Zope to ensure that newer issues don't conflict with old issues. In practice this is very very hard to achieve, especially if you want to use all the features of Zope (external methods, database connection, contents from file system, etc.) You have to decide up-front what you define as an "issue" of your magazine. Many websites nowadays change from one minute to another, so it's virtually impossible to archive an "issue" without losing some information. If you are serious about archiving a past issue in its total integrity, you need more than just one Zope, if not more than one machine. In my opinion, that's not the way to go nowadays: websites are becoming more and more interactive, and the concept of "issue" is murkier and murkier. If you have some static pages you want to archive, probably you can get by just by using mirroring programs like wget (in Unix) or other shareware programs in Windows (search in www.shareware.com, www.download.com, etc.) and grab a snapshot of your whole website, then burn a CD and call it done. :) Of course, if you have more interactive elements (form inputs), you will be very miserable trying to keep the whole version... the best thing in that case would be freezing the entire Zope site (your whole Zope folder, with all external methods, database files, local file system content files, etc.), possibly into a CD, too. Anyway, you have to decide where to cut the cake. There are trade-offs between: - interactibility - dynamic content / static content - time - money - earthquakes, fires, or other natural disasters - lawsuits or other unnatural disasters No one else can cut your cake except yourself. :) But Zope's versioning device will only play a very tiny role, that's for sure. regards, Hung Jung ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com