Re: [Zope3-Users] need guidance
Hi Brad, On Tue, 2005-11-29 at 21:07 -0600, Brad Allen wrote: [...] > Ok, so this kind of discussion makes me wonder how much I can do > without ZODB, or at least whether I can just use the ZODB files like > any other binary files in the SVN repository. Having to write scripts > to regenerate them sounds like a lot of ass-ache. Is there any reason > why I can't just check in those data.fs files into SVN along with my > Python packages, so that other team members can check them out into > their respective Zope instances? I might be missing something but not sure why would one want to store a database in SVN. I could understand that people doing TTW Zope 2 development would have source code in ZODB but Zope 3 does not have any TTW development functionality at the moment and all of your source should be on the file system. Python scripts could automate building a site or site utilities and I would have that sort of stuff in svn. But as far as persistent content goes this is more of a data backup/migration issue. fssync I think was mentioned on the list for pulling content objects out of ZODB in Zope3 on the file system but not sure if it is available yet. Alen ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] need guidance
So this style of Zope 3 development involves not using ZODB so much for permanent storage, but instead as a temporary scaffolding on which to hang the current version of class instances and their content. When you refactor your classes and interfaces, you just re-instantiate everything into the ZODB to recreate the site. For development, yes. It sounds great, except not all data can be simply regenerated. For stuff like port numbers and configuration, fine, it can be in ZCML or embedded in Python scripts. But the site content generated by end users has to be stored somewhere, too,. If you throw away your ZODB and regenerate it, what happens to that data? Does your regeneration script transfer all that data to the newly generated ZODB? While you're developing, it's much easier because the *content* in your ZODB doesn't typically have any value during development. If it does have value during development, you have a development model that's not similar to mine. But obviously, after you go into production, the content does have value, and preserving this value is the purpose of GenericSetup for Zope 2. It's a "dump and reload" solution which allows you to create a represention of your ZODB data and its associated hierarchy as files on a filesystem. You can basically push a button to dump the data in your ZODB ro files, and then create a new ZODB, instantiate the tool, and push a button to reload it. Zope 3's "filesystem synchronization" capability is similar in concept, although I don't know if that has been maintained recently. I'd be interested in seeing the particulars of how you guys do that stuff. I do it all the time for customer jobs and there are examples in CMF for Zope 2 (e.g. the "SiteGenerator") but I don't have any code that uses Zope 3 that does site generation. I've yet to run across a direct mention of how to create an arbitrary ZODB and start reading and writing objects. That seems to be a big piece missing from my understanding of how to work with Zope 3. Every ZODB example I've seen in the books seems to involve creating a content object that can be added via the ZMI. However, I'm not finished with either book, and I have very likely missed something. There are tons of examples about how to access ZODB data outside of the context of Zope around, do a little googling. The thing that might make it a little mindbending is that "accessing data in ZODB" is just.. Python. You open the database, get the root Zope object, and then traverse to an object in the database (usually via getattr or getitem or whatever the folder API is) and call methods on it or read attributes from it or whatever. There's really not much to it. It's largely the same as writing code in your content classes, but you can do it from a Python prompt. Zope 2 has "zopectl debug" which dumps you off at a Python prompt with the name "app" built in to the root Zope object. Note that this is not particular to any version of Zope. Zope is just a consumer of ZODB, and the issues are the same no matter what consumer of ZODB you're using. - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] need guidance
Duncan McGreggor <[EMAIL PROTECTED]> It sounds like a pain, and to be honest, at first it is a bit arduous. Not only does it get faster and become second nature, but chunks of it can be generalized and reused. It really doesn't take that long to get accustomed to it. And once you start doing it regularly, you gain a tremendous amount. Not just in the mere knowledge acquired, either... there's a subtle shift in your programming where you give extra attention to the data-generating/-populating code, which in turn makes you architect your information better ahd brings higher overall levels of organization to your project. So this style of Zope 3 development involves not using ZODB so much for permanent storage, but instead as a temporary scaffolding on which to hang the current version of class instances and their content. When you refactor your classes and interfaces, you just re-instantiate everything into the ZODB to recreate the site. It sounds great, except not all data can be simply regenerated. For stuff like port numbers and configuration, fine, it can be in ZCML or embedded in Python scripts. But the site content generated by end users has to be stored somewhere, too,. If you throw away your ZODB and regenerate it, what happens to that data? Does your regeneration script transfer all that data to the newly generated ZODB? I'd be interested in seeing the particulars of how you guys do that stuff. I've yet to run across a direct mention of how to create an arbitrary ZODB and start reading and writing objects. That seems to be a big piece missing from my understanding of how to work with Zope 3. Every ZODB example I've seen in the books seems to involve creating a content object that can be added via the ZMI. However, I'm not finished with either book, and I have very likely missed something. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] need guidance
On Nov 29, 2005, at 10:29 PM, Duncan McGreggor wrote: Additionally, the ability to generate a new instance of a project complete with a fresh-and-ready ZODB is of immense value when working on a project with multiple developers or teams of developers. Several times, we have saved literally days of work taking advantage of this. I'm sure others that take even better advantage of this have saved perhaps weeks. Yes. You could also just check in a generated database into CVS and use that with some of the same benefit but FWIW, I find the biggest value in being able to review this kind of setup code is that it serves as a kind of documentation as to *how* an iinitial database got created. Also, setup code is often complex and subtle because it's "where the rubber meets the road" in a production configuration. Being able to replicate it on demand with subtle changes (like port numbers and filenames) is valuable when you want to roll out a system into production. - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] need guidance
On Nov 29, 2005, at 10:07 PM, Brad Allen wrote: Chris McDonough wrote: Here is another question. Suppose I'm working with a team of developers. Should we each set up our own separate Zope3 instance, and do SVN checkouts into our own separate, local /lib/ python directories inside the instance? How then would we merge any changes done in the ZODB? On the other hand, having all team members try to share a single Zope 3 instance seems unworkable... I wrote a short treatise on this subject at http://www.plope.com/ Members/chrism/zope_collab/view that you may want to take a look at. It's written with Zope 2 in mind but the issues and mechanics remain the same. Ok, so this kind of discussion makes me wonder how much I can do without ZODB, or at least whether I can just use the ZODB files like any other binary files in the SVN repository. Having to write scripts to regenerate them sounds like a lot of ass-ache. Hehe. I like that description. ;-) Yes, it is. Although there is at least one tool that helps with just this called GenericSetup for Zope 2. I suspect that tool could be made to work with Zope 3 with a bit of work. Is there any reason why I can't just check in those data.fs files into SVN along with my Python packages, so that other team members can check them out into their respective Zope instances? No, as long as your code matches the pickles in the database binary stored in CVS. The problems start when you need to change the code in a way that makes the pickles in the database incompatible with the code; for example if you need to change the name of an instance attribute in one of your classes; the pickles have the values stored in the old attribute name and your new code expects the new attribute name. So the code fails on the old data. This is of course the same problem you have when you need to change the schema of a relational database and you have an existing database instance. That said, Zope 3 comes with a tool named "generations" that allows you to evolve database pickles in a uniform way by writing evolution scripts. - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] need guidance
On Nov 29, 2005, at 8:07 PM, Brad Allen wrote: Here is another question. Suppose I'm working with a team of developers. Should we each set up our own separate Zope3 instance, and do SVN checkouts into our own separate, local /lib/python directories inside the instance? How then would we merge any changes done in the ZODB? On the other hand, having all team members try to share a single Zope 3 instance seems unworkable... I wrote a short treatise on this subject at http://www.plope.com/Members/chrism/zope_collab/view that you may want to take a look at. It's written with Zope 2 in mind but the issues and mechanics remain the same. Ok, so this kind of discussion makes me wonder how much I can do without ZODB, or at least whether I can just use the ZODB files like any other binary files in the SVN repository. Having to write scripts to regenerate them sounds like a lot of ass-ache. Is there any reason why I can't just check in those data.fs files into SVN along with my Python packages, so that other team members can check them out into their respective Zope instances? It sounds like a pain, and to be honest, at first it is a bit arduous. Not only does it get faster and become second nature, but chunks of it can be generalized and reused. It really doesn't take that long to get accustomed to it. And once you start doing it regularly, you gain a tremendous amount. Not just in the mere knowledge acquired, either... there's a subtle shift in your programming where you give extra attention to the data-generating/-populating code, which in turn makes you architect your information better ahd brings higher overall levels of organization to your project. Additionally, the ability to generate a new instance of a project complete with a fresh-and-ready ZODB is of immense value when working on a project with multiple developers or teams of developers. Several times, we have saved literally days of work taking advantage of this. I'm sure others that take even better advantage of this have saved perhaps weeks. I give it two thumbs up ;-) d ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] need guidance
Chris McDonough wrote: Here is another question. Suppose I'm working with a team of developers. Should we each set up our own separate Zope3 instance, and do SVN checkouts into our own separate, local /lib/python directories inside the instance? How then would we merge any changes done in the ZODB? On the other hand, having all team members try to share a single Zope 3 instance seems unworkable... I wrote a short treatise on this subject at http://www.plope.com/Members/chrism/zope_collab/view that you may want to take a look at. It's written with Zope 2 in mind but the issues and mechanics remain the same. Ok, so this kind of discussion makes me wonder how much I can do without ZODB, or at least whether I can just use the ZODB files like any other binary files in the SVN repository. Having to write scripts to regenerate them sounds like a lot of ass-ache. Is there any reason why I can't just check in those data.fs files into SVN along with my Python packages, so that other team members can check them out into their respective Zope instances? ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] (Ab)using utilities
Hi, in an application we build using Zope 3, I've been noticing a tendency to use utilities quite a lot. For instance, suppose we have a top level container which holds items of type one. There are also items of types two and three somehow connected to the top level container. To avoid having to filter item types all the time, we don't just want to mix them in among the type one items. However, we don't want to put folders in the top level container to hold all type two or type three items, resp., either. The reason being a feeling that such folders would not provide well-defined enough access: they might be renamed, or there might be more than one folder holding items of either type. Our current solution is to register utilities that handle type two and three items, and turn them into folders actually containing the items while we're at it. This does provide uniqueness of the type two and three item containers, as well as well-defined access by an interface name. However, I'm not at all sure that containing application data is what utilities are meant for. Is it? I get a feeling that we might want folders as attributes of the top-level container, for all the uniqueness and well-defined access that provides. But would that be Zope-3-ish? -- Thomas ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] need guidance
Hi Brad, On Nov 29, 2005, at 5:45 PM, Brad Allen wrote: Here is another question. Suppose I'm working with a team of developers. Should we each set up our own separate Zope3 instance, and do SVN checkouts into our own separate, local /lib/python directories inside the instance? How then would we merge any changes done in the ZODB? On the other hand, having all team members try to share a single Zope 3 instance seems unworkable... I wrote a short treatise on this subject at http://www.plope.com/ Members/chrism/zope_collab/view that you may want to take a look at. It's written with Zope 2 in mind but the issues and mechanics remain the same. - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] need guidance
I'm still in the midst of an effort at learning Zope 3, while try to build a real website for it. I have ambitions for using Zope 3 in several different projects, and am actively working on a Zope 3 website that I hope to have looking presentable if not fully functional by mid-December. It will probably look a lot like a static site at first, with a few added features like messageboard functionality (I hope it will be ok for me to use MessageBoard from Stephan Richter's book for a non-profit site). Later we will want to add features for wiki, blogging, event calendar, and document library. Another Zope 3 project for the future is to convert an ecommerce site I had previously built in PHP. I've been using Python at my day job now for a couple of years, and have decided I no longer have time for PHP--I want to switch the site to Python, probably using Zope 3. This site's main purpose is to allow customers to search, view, and purchase from a catalog of auto parts. With these two different types of sites in mind, some design questions have come up in relation to Zope 3. For the auto parts site, I am thinking about designing an AutoPart content component. This will allow the business owner to edit his catalog of auto parts via the web. Suppose he starts instantiating a lot of auto parts, and editing them. Later, we decide we need to refactor the base class, and maybe create a few child classes. That leaves me with a big cleanup chore, because a lot of old AutoPart instances are sitting around in the database. What's the normal pattern for dealing with this kind of cleanup? Am I better off just using SQL tables to provide persistence, and not storing my object instances in ZODB? At least with SQL, it's easy enough to manipulate the content data, and just re-instantiate AutoPart objects from SQL when needed. I'm trying to come to an understanding of when it's best to keep data in the ZODB, and when it's best to use SQL instead. Maybe there are tools for handling ZODB data that I don't know about. Another question about ZODB is whether to use it to store page templates. If I build a lot of ZPT pages and macros and store them through the ZMI, and then later want to rearrange the folder structure, I'm guessing it will be a pain to change a lot of hard-coded path references. If I use text files outside the ZODB, then I can use a host of text editor tools for searching across multiple files. I like the idea of letting end users have something like the ZMI for editing content, and am hoping it will be possible avoid putting much TAL and METAL markup in documents in the ZMI, but rather have the .pt files pull content from the ZODB. However, it's not clear to me how to make that work. The examples in the books have the .pt files in the filesystem; I don't recall seeing any the ZMI/ZODB. Here is another question. Suppose I'm working with a team of developers. Should we each set up our own separate Zope3 instance, and do SVN checkouts into our own separate, local /lib/python directories inside the instance? How then would we merge any changes done in the ZODB? On the other hand, having all team members try to share a single Zope 3 instance seems unworkable... Thanks for any insights you can provide. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
