On Nov 29, 2005, at 3:45 PM, Brad Allen wrote:
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.
Do you have a zope2 background? With a background in zope2 and twisted,
I found z3 very easy (delightful) to learn. My first z3 site was done
from scratch, with graphic design, custom user-editable content in
under 3 weeks. I was an instant z3 fan.
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.
You will definitely want to start getting familiar with pythonic site
creation in z3, particularly, setting up a catalog (IntId, Catalog,
Index-creation, etc.). All of my query needs are met (so far) by simple
python calls to catalog.SearchResults and then a lambda for sorting.
Martijn Faassen wrote a great query wrapper called "hurry" that you
will almost certainly want to investigate/use:
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.
As Chris mentioned before, to my understanding, this is a perfect
use-case for generations, so you should be covered (if it's up to
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.
As a general trend, people that have highly-relational data tend to
prefer using RDBMSs. I have no current projects for which I use an
RDBMS, but I have in the past. I also have a very strong preference for
object databases ;-)
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
I think this has been answered. There's no current TTW dev. But you
will come to dearly love filesystem dev, especially with multiple
developers working on the same code ;-)
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.
Perhaps I can clarify with a typical example:
* you have a z3 project, all the code is on the file system
* you will create custom content objects
* you will create a "skin" for the project -- this is how it will look
to end users
* you can use the ZMI for administration tasks (such as
creating/editing content) -- you can customize the ZMI to look like
anything you want
* you can modify your custom skin to present various editing/management
options to the end users
Perhaps this makes thins more clear?
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?
IMO, definitely ;-)
Zope3-users mailing list