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 . . .
Zend is PHP, Zope is Python.
the best language out there.... especially for the price! Too bad it has such a silly name. Any /.'er willing to discuss how you have implemented it as a back end for a relational database?
EHR
I know, one doesn't know until doing, but I honestly am trying to figure out whether to use Zope or not. Most of the sites I work with right now are about internal data presentation and have very little involvement with individuals that need to customize sites often.
Does anyone have a short and sweet description of where Zope really turned out to be an awesome tool?
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.
they do fix up their snafus every once in a while!
sic transit gloria mundi
It's released under the OPL and both an HTML version and a PDF version of the book are freely available.
:wq
he was a paratrooper. is he the only french guy that actually does any fighting?
the french ar such pussies!
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
The name 'Bible' is condescending. It implies that the book is the be-all, end-all. Why can't it be a 'tome' or "big f'n guide to zope"? I like Python as much as the rest of you, but why is every big book a 'Bible'?
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'm glad to hear they cover RMDB integration. I think a killer book would focus exclusively on Zope, Python, and RMDBs.
As a relatively new user of Zope/Python, I have to say that they are both unbelievably flexible and easy to use *once* you figure out how to use them. This is great because instead of thinking "Jeez, what a pain in the butt!", I keep thinking "Of course!". Still, it means that early on I occassionally had to figure stuff out without documentation (though this last year has seen maybe three or four new Zope books, so that's no longer the case.) With more quality documentation, I suspect a lot of people will be turning to Zope/Python. It's just too easy and too good.
BTW, for those interested in a nice companion to Zope, I found Python Web Programming by Steve Holden to be a killer how-to book. It took me from 0-60 in a few days. If I ever meet Holden, I'm definitely buying him a beer.
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.
I dunno, I thought the original bible had some interesting stories but was overall pretty spotty and even contradictory at times.
mark
If you want to make an apple pie from scratch, you must first create the universe. -- Carl Sagan
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.
You know I thought the best part of the book was the inclusion of a PDF of both the book and the Python Bible. I love being able to find what I am looking for easily with PDFs. I also don't have to haul the book with me to get the information on those long flights.
Why waste perfectly good database space with a bunch of -1 posts? Why can't some people have Uber Moderator powers so they can just delete this stuff?
I think the trolls themselves are probably arguing for the same kind of more direct editorial management of slashdot. The goal of terrorism, after all, is to wake people up to the flaws of the system.
how about
"Zope for you"
"PHP for you"
"Perl for you"
GNU/for you
-- Hasbullah bin Pit (sebol)
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!
For those who want to whett their Zope appetite, try www.freezope.org a cool free zope hosting site, allows you some control through DTML, and python scripts.
When I first saw Zope, it was as a "collaborative development platform". After over 2 years of using it, I still only have half a clue.
Paid to be a "helpdesk analyst" for proprietory POS software and not to code, I've been learning Zope for over 2 years. In another year, I'll be ready to build a full python Product. Most of the lag is the free time issue, some is development process.
I'm glad I've read this review before seeing it on the shelf. I've bought _The Zope Book_ and _Zope Web Application Development Kit_ and have found both only partially helpful. The DTML reference in TZB, once helpful, is now older than the publishing process with ZPT/TAL seems to be "the way to go".
Stated elsewhere, I think my next Zope book will be by O Reilly. I'm beyond the basics, and am in need of a good reference book, not selected chapters/parts of several books.
All in all, Zope works well and provides a suitable collaborative development environment, and the price is right (GPL). It's also a great introduction/immersion into object oriented programming.
Plus ca change, plus c'est les memes choses.
A reviewer at infoworld.com suggested that Zope was built by "OOP Zealots" (paraphrased) instead of with practicality in mind. (Sorry, I cannot find the article anymore. It is roughly 18 months old. If I find it again, I will post a link.)
Why try to reinvent OODBMS' when the market has rejected those silly, contorted things? When OO hype builds up OOP product sales, you zealOOts claim victory, but hypocritically keep hugging OO technologies, like OODBS, that the market has pissed on.
oop.ismad.com
And, just because I don't like OO does NOT make me a troll. One can hate MS around here without getting modded down, but mention OOP, and kaboof! from the evidence-free OO-cliche lickers. Mod me down ONLY when you have fricken evidence that OOP is objectively better in all domains.
Table-ized A.I.
I'm really trying to get a grasp on what the hell it is. The article is marvelously lacking on the subject.....