Absolutely, for the places where configuration that is changed TTW can't be kept in files on the file system like, historically, workflow definitions or other tool settings, these objects need to have an import/export mechanism. I have to admit that dealing with ongoing development on a Zope site that has gone into production is something I haven't needed to to a lot of (which is pretty sad, actually).
That gets me to thinking. Given the general amount of confusion caused by the historical overhyping Zope *itself* as a collaborative development environment, at some level, I can empathize with AMK's "Why we don't use Zope" article (http://www.amk.ca/python/writing/why-not-zope.html). It's important that folks understand the limitations of the TTW development model; they risk becoming disillusioned with Zope if they don't. Ah well. At some point, the Zope-as-OS project will be completed. You know that day has come when we embed Emacs. Or vice versa. ;-)
Zope 3 persistent modules and "ZVS"
Posted byzopepaulat
2004-01-02 02:36 AM
I think there are still benefits to TTW Dev and storing code in the ZODB. As you've mentioned, though, in group development on larger projects, these benefits go with an important list of drawbacks.
If you lined up the benefits and the drawbacks, I think the direction Jim is going with "Zope 3 TTW":http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ThroughTheWebDevelopmentInZope3 (hmm, wonder what STX will do with that link...) addresses a number of the weaknesses while keeping, or improving, some of the benefits. This combines with the "File System Sync":http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FileSystemSynchronizationProposal proposal.
Though these proposals don't deal directly with bootstrapping a bunch of data, it's a logical extension to these proposals. How do you feel about being able to have your code live, during development, in both CVS/Subversion and the ZODB? Which of the drawbacks would remain?
That gets me to thinking. Given the general amount of confusion caused by the historical overhyping Zope *itself* as a collaborative development environment, at some level, I can empathize with AMK's "Why we don't use Zope" article (http://www.amk.ca/python/writing/why-not-zope.html). It's important that folks understand the limitations of the TTW development model; they risk becoming disillusioned with Zope if they don't. Ah well. At some point, the Zope-as-OS project will be completed. You know that day has come when we embed Emacs. Or vice versa. ;-)
If you lined up the benefits and the drawbacks, I think the direction Jim is going with "Zope 3 TTW":http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ThroughTheWebDevelopmentInZope3 (hmm, wonder what STX will do with that link...) addresses a number of the weaknesses while keeping, or improving, some of the benefits. This combines with the "File System Sync":http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FileSystemSynchronizationProposal proposal.
Though these proposals don't deal directly with bootstrapping a bunch of data, it's a logical extension to these proposals. How do you feel about being able to have your code live, during development, in both CVS/Subversion and the ZODB? Which of the drawbacks would remain?
Replies to this comment