Zope dos and don'ts

It was once said to me that what Zope really needed was a list of "Dos and Don'ts" to help steer people on the "right way" to use Zope in 2004. Over time, methods have come and gone, and more ways to do things emerge. This list tries to provide a very simple guide of the things you should and perhaps should not do. Please add your own ideas!

Do

Use Page Templates

When starting anew, pass DTML by. It may take a little bit to learn them but they are simple and elegant once you do.

Use Python

When you need to add business logic, add some Python. For simpler things, Python Scriptss are the ticket. If you run into the limitations of Python Scriptss try ExternalMethods. For more advanced tasks, or if you end up with a lot of ExternalMethods, a Disk-based product may be the solution. Python is easy to learn, don't be afraid.

Use a ContentManagementSystems like Plone or CPS

So many hard problems have already been solved for you. You'll need to make less unimportant descisions. It's well worth the extra time to learn.

Use ZODB (Zope Object Database)

If you started Zope, you already are. Take advantage of it.

Use ZopeProducts

It's very unlikely you are the first person to encounter the problems you are faced with. See how others have solved them. Ride on their shoulders.

Make it modular

Make each part of your application as simple as possible. Break it up into digestible chunks. Separate concerns, divide big complex things into many simpler things. Folders are your friend.

Use the Mail lists

There are many helpful people out there. They read the lists. Lurk, post, ask questions, answer questions. Be right or be wrong. Don't be shy.

Use the source, Luke

It's Open Source for a reason, so you can read it! Wanna learn how to write the next killer app? Read the code from the last one. Beg borrow and steal the ideas and code. Make it better, faster and stronger. GiveItBack.

GiveItBack

You take, you give back, it's the fair way. Make yourself useful. Promote Zope in your own way. Write the next killer product. Write some docs. Make a cool Zope graphic. Create your own community website, post on others. Go to a conference, tell people what you've learned. Help on the Mail lists. Rant and rave. Become a Zope contributor.

Keep it simple

Simple is beautiful. Simplicity is complexity tamed. Simple is often harder than complex, but always better. Simpler is not always smaller. Ride the tension between simple and modular. Start with the simplest thing that could possibly work, prove that's not good enough.

Refactor

Do it again. Make it better this time. Learn from your mistakes, write about them. Expect that you will know better tomorrow, make peace with that.

Write Tests

The improvement in the quality of your work, and the greatly increased speed of future code maintenance, is well worth the time investment. Consider using ZopeTestCase.

Have fun

Otherwise, why bother?

Don't

Use ZClasses

see ZClassesAreEvil -- Therein lies the dark path. Instead, use Disk-based products

Mix Concerns

Keep presentation, content and logic separated. SeparateContentAndCode. Put global logic in global tools. Keep the mechanism free of policy. Don't configure using software.

Over-Design

Zope is a rapid application development tool. Use it. Make working prototypes from ideas. Sketch in software. Iterate and refactor.

Reinvent the Wheel

Build on someone else's work.

Be Clever

When stupid and simple will do.

comments:

Don't configure using software? -- Tue, 06 Jul 2004 00:36:02 -0700 reply
Could you elaborate? I'm not sure what you mean. I'd much rather have a workflow programmatically setup during e.g. Plone product install, than import it from a zexp.

Don't configure using software? -- Sat, 10 Jul 2004 14:10:01 -0700 reply
Maybe he means hard-code. I.e., configuration should be in configuration ''files''

Use ZODB (Zope Object Database) -- Thu, 21 Oct 2004 09:49:17 -0700 reply
For many practical purposes, having easy access to external RDBMSes? is a basic requirement. Many Zope promoters seem to gloss over that and instead trumpet the superiority of the ZODB (Zope Object Database), even in cases when it isn't, or when using the ZODB (Zope Object Database) is out of the question. Very religious.

Re: Use ZODB (Zope Object Database) -- Thu, 05 May 2005 00:22:07 -0700 reply
The point is possibly that many people coming from php (and similars) have a hard time changing their way of working. They tend to put up an SQL db and want to put everything in there. Really, really often that is just a waste of time, since an object database fits the bill much better.

use ZODB (Zope Object Database) --PeterD?, Mon, 26 Mar 2007 00:08:46 +0000 reply
RDBMS are simply one of the realities of enterprises, and not the worst one by far (if you have ever seen databases in Access you know what I mean). ZODB (Zope Object Database) would be a much easier sell if there were tools to transparently and reliably map back and forth. I use Zope because I like python and ZODB (Zope Object Database), but I need RDBMS. If that doesn't work out I'd rather do RoR? than any of the Python web frameworks that try to imitate PHP or Rails.