Slashdot Mirror
Zope Bible
Part One is the basics, which anyone familiar with Zope can skip over if they so choose. For a newcomers it may seem a little overwhelming, but for readers unfamiliar with web development it may seem a light on details at times. It opens with the obligatory "History of Zope" which is mercifully brief and includes a single paragraph on the history of the Internet that publishers still insist on including. It does mention some great high-profile organizations that are using Zope (Red Hat, NASA, Bell Atlantic Mobile, CBS, and the U.S. Navy). The Features section could be used to great effect in selling the use of Zope to management, as it is brief and to the point and focuses on things that businesses actually care about. Next up is Architecture, and the Bible does a fine job of describing the Zope architecture and highlights the primary advantages in nice bullet points (Cost of ownership, RAD, reliability, scalability).
Installation is covered with proper dispatch and goes into great detail about the ZServer (the preferred web server) as well as how to install new products and troubleshoot bad installations. The basics of the Zope Management Interface and the Control Panel are covered in chapter three.
Chapter Four is where the meat starts. This is a fairly in-depth presentation of DTML, Zope's built-in markup language. It includes a nice reference to Python modules natively available in Zope, and examples of all standard tags in action. Closing out Part One is a chapter about Object Oriented Programming in Python. It is less detailed than the documentation and tutorial that come stock with Python, and anyone who plans on getting that down and dirty will want to get a real Python book. Those 50 pages would have been better used in providing a case study or two of developing an end-to-end web app in Zope. Even given the focus on writing things in Python, this section isn't actually helpful.
Part Two begins with an example of writing your own Zope product in Python (though not one that actually does anything useful), rapidly followed by the process of creating a real product in Python. Given the detail and scope of the AddressBook products, there is no need for the first "create a product" example. Chapter 8 continues with adding functionality to the AddressBook product.
Chapter 9 is Zope Product Security. This chapter explains both what Zope will and won't do for you, and how to determine security requirements and policies. Chapter 10 finishes up the AddressBook application and explains the use security concepts to control levels of access. The order is slightly awkward: it would have made more sense to introduce security concepts before going down the entire create-a-product path, rather than take a side trip in the middle.
Part Three: Management. Not PHBs, but application management. This starts off with Content Management. If you remove the specific Zope examples, you have what amounts to a best-practices guide to web development regardless of language. This is a Good Thing(tm). Database Management assumes zero familiarity with databases and provides a nice basic intro to databases and specifically how to connect assorted DBs to Zope as well as how to integrate SQL with DTML. The last part of the triumvirate is User Management and Security. This section covers the basics (users/roles) and a very light taste of addons, but really could stand a bit more breadth.
Part Four is called Advanced Zope Concept, or "everything that doesn't really fit anywhere else." ZClasses can hardly be considered an advanced concept, especially when compared to rolling your own product in Python. Zope Core components is a compilation of basic OO concepts (acquisition, persistence), the ZODB, ZPublisher, and Document Templates. This is another section that could have been better served by more detail. DocumentTemplates is breezed through with no detail whatsoever.
Scripting Zope demonstrates once again how to extend Zope using Python and covers scripting with Perl in just under two pages.
ZClasses, which have in the past been the most common method of writing Zope products, are discussed in fair detail, including a nice comparison of ZClasses -vs- PythonProducts.
Chapter 17 covers searching, describing how the ZCatalog works and how to leverage it. Zope Page Templates warrant their own (very brief) chapter which explains the shortcomings of DTML (HTML-editor unfriendly, not renderable, mixes presentation and logic) and gives a decent overview of the new PageTemplates that are meant to replace DTML in many instances.
Debugging is another light chapter, though it does cover the essentials fairly well. Finally comes Alternative Methods of Running Zope. This, as you might expect, explains how to use Zope with Apache/IIS and also addresses scalability, with a focus on Zope Enterprise Objects.
The appendices consist of What's On the CD-ROM and Installing Zope from the Red Hat RPMS or Souce Code.
What's Bad?
Zope Bible is a misnomer. There is a lot of great information here, but many sections are to shallow to be of any use. A more appropriate title would be "Python for Zope" or "Advanced Zope Development with Python." The book claims to be aimed at beginning to advanced users, but it is not organized in a manner that will be useful to Zope newbies and the things a beginner needs to know most often are missing or covered in such little detail as to be as good as missing. They could have dropped the first three chapters, and used that space to flesh out some of the later chapters and perhaps do a second case study.
What's Good?
The sections that are good are very good. The authors obviously have a deep understanding of Zope, and I didn't catch any technical errors. The writing is clear and effective. If you're already familiar with Zope and already have The Zope Book and The Book of Zope, then this would be a great next book for getting more into the Python parts of Zope. I particularly liked that they built an actual useful product from end to end in the course of several chapters explaining how different features of Zope can be used. The reference sections on CM and DBM are great. It's nice to see some aspects of Zope that are woefully underdocumented get addressed (Templates, DB integration, Security, Searching) even if some of them aren't in as much detail as I'd like.
You can purchase the Zope Bible from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
Just curious as to why this story was classified as PHP when Zope is Python . . .
to be rather lacking. I never even consider them when I am looking for a book on something, anymore. I just go straight for the Wrox and O'Reilly offerings (in that order, actually).
sic transit gloria mundi
Lots of computer books start with a title and go from there. I've heard more than one author say, "Hey, this is the title I was told to use. Somebody thinks the book will sell better if it has 'Advanced' or 'Power User. in the title.
It's released under the OPL and both an HTML version and a PDF version of the book are freely available.
:wq
My first experience with Zope was "Hi, it's your first day and we want to migrate our website to Zope. We've never used it, but our architect thinks it looks interesting." I'd heard of neither Python nor Zope before, and had it up and running in 2 days. www.planetcad.com
this is getting old and so are you
blog
I find it very difficult to read. I have difficulty reading more than a couple of pages before wanting to put it down.
More a reference book I think.
Deleted
I have found that if a book is call "bible" by its author/publisher, it never is (not that I have see, anyway; flames/exceptions to /dev/null ;-).
If it is called "bible" by users, it usually is.
room101 -- how much can you stand before they break you?
(they always break you eventually)
I used to develop for the ACS, which in some ways was regarded as a direct competitor to Zope, to the point that a Zope user wrote up a pretty even-handed comparison between the two. He said things like, "Well, we have the ACS beat on feature X, but they have us beat on feature Y." At that point, I would look over at the sorry state of feature Y on our system and think, "Wow, if feature Y scares them then our FUD is working."
I remember the first time I installed the ACS, I was impressed with the out-of-the-box functionality. But after getting on the inside, I learned that the ACS was little more than some threaded discussion lists, user scripts, and a moderately beefy intranet module. Looking back, I could have written the whole thing myself, and in fact we did on our client projects, where the ACS was eventually overwritten with custom code. A good starting point, perhaps, but not much more.
If that wasn't bad enough, the ACS went towards an object model, proprietary markup language, and content management - just like Zope - which promply drove the company out of business.
I wish the Zope team luck, they probably made more correct design decisions than we did. They survived long enough to put out two books. But to me, web toolkits are kind of like white elephants. They promise glory but in the end they are just massive, hungry, messy beasts.
Zope has to be one of the coolest open-source projects I have ever used. You can literally build a site from scratch to completion in a matter of hours or days (depending on complexity) if you know what you're doing.
I used to work for a company that built a very large ZCatalog-driven site (with over 300,000 items in the ZCatalog, interfacing to an Oracle backend with over 3 million items). Zope was an excellent development platform, and I still use it on personal projects.
The biggest thing keeping Zope for blowing other products like WebLogic and StoryServer out of the water is the steep learning curve. It took me a good month to get up to real speed on Zope, and I had a background in python. Zope relies on some very powerful base-class "magic" to make everything work, and some of that behavior is hard to grok (acquisition, ZClass/Python-class dichotomy, the ZCatalog, the BTree implementation, and the various ZODB Storage options come to mind).
At the 2001 Python conference, the Zope-Corp (nee Digital Creations) folks said the learning curve was a high priority for future releases. I hope so, because Zope and python are great technologies for those who make the time investment necessary to learn them.
- Vincit qui patitur.
But I still say they're brand-obsessed.
Register that trademark!
You seem to have offended the religious sensibilities of a moderator. Is it just me, or are moderators getting more intolerant?
This seems like a good place to mention Squishdot, a weblog product for Zope. Its claim to fame is that it looks quite like Slashdot, though it is missing some features.
If you're looking to build a stripped-down slashdot-like site, Squishdot and Zope may be the answer.
I'm sure Zope is much simpler than it looks, and after working with it awhile, you get to a point where it's all crystal clear. But I could never get to that point- everything is obscured by silly new paradigms, acronyms, and taxonomy. It's all just too zilly for me. After ztruggling with Zope for what zeemed like a zentury, I picked up OpenACS and built a website with it in about three weeks.
This means that a good zope developer has to know quite a lot.
The problem that is now facing beginners is that the toolset is rich enough and the advice offered is disparate enough that they are ususally confused for quite a while.
DTML is ugly, is no longer encouraged, etc. It is also easy to pick up. You really want to use only dtml-var, dtml-in, and maybe dtml-if.
TAL/METAL is an XML dialect that is supposed to be GUI designer tool compatible and still allow limited program expressiblity. This is what most of the gurus use now, rather than DTML. To my eyes, it is even uglier than DTML.
For more complicated constructs, use Script (Python) methods. Most of the power of python, reasonable attempts are made to keep programmers from accidentally opening security holes.
If you need more power than that, and carefully think about security, python is avaliable in external methods. The biggest issue here is that no security checks are made and the programmer must have write access to the file-system; something that is not required for Script (Python).
And finally, you can build your own extensions, most people seem to be using pure Products, these days. There are a couple HOWTOs on the process.
With this number of independent choices (ZOBD/filesystem/SQL database), (DTML/TAL/Script (Python)/External Method/Product); and with the number of things that you have to worry about with a number of different kinds of people zope is targeted at (website designer, DTML/TAL developer, python developer, SQL administrator/developer, product developer, core developer), it is no wonder that these books are a bit schizophrenic and skip from high point to high point.
My best advice is that 1) if you want to be anything other than a website designer, you better know HTML very well. 2) Do something like a simple phone book application. Pick one programming language (DTML/TAL/python), and one data store (ZODB, SQL, filesystem). Try to learn as little as possible. It will probably take you about ten days; and you will be ready to chuck the mess out the window. 3) Now, throw everything away. Do your phonebook again, without refering to anything in your old design. You will probably find that you can do it in about 4 hours. When that point comes, you find that, yes, the initial headaches are worth it; and that, most of what you learned ended up not coming from the book anyway.
As a final remark, the phone book exercise is worth repeating every six months or so. Use the same toolset, or a new one. Think of ways to generalize it, sort orders, reverse lookup, etc. You will be astonished at how much better you get and how much the choice of problem influences the choice of toolset!