Zope Bible 94
The Zope Bible | |
author | Michael R. Bernstein, Scott Robertson & the CodeIT Development Team |
pages | 613 |
publisher | Hungry Minds |
rating | 8 |
reviewer | the_rev_matt |
ISBN | 0764548573 |
summary | An in depth look at extending Zope with Python. |
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.
Why was this classified under PHP? (Score:3, Informative)
Re:Why was this classified under PHP? (Score:2)
Although I do not see this argument working too well when Linux stuff starts appearing in the BSD section.
Re:Why was this classified under PHP? (Score:1, Insightful)
Re:Why was this classified under PHP? (Score:1)
Zope isn't PHP (Score:1, Informative)
I'm really trying to get a grasp on whether use it (Score:1)
Does anyone have a short and sweet description of where Zope really turned out to be an awesome tool?
Re:I'm really trying to get a grasp on whether use (Score:2)
I've always found the Bible series (Score:3, Interesting)
Re:I've always found the Bible series (Score:2, Interesting)
Of the 20-odd O'Reilly books that I have, most are quite good. The same applies to Wrox although Wrox's are usually more "tutorial-like" and as such better for a begineer. I feel the animals are usually more in depth and the writting is somewhat better (probably explained by the fact that there's 20 authors on a typicial Wrox book).
My only other complaint about Wrox is that it looks like they reduced the quality of the paper they use latelly.
All in all, both are goods and are my first choices except where there is some high quality hardcover available.
Bible books are a big no-go as is mostly everything that starts with "exceptionnal", "bible", "unleashed", "dummies", "whatever".
Re:I've always found the Bible series (Score:2)
Btw, is it just me, or does the guy in the second photo from the left in the bottom row on the cover of that book, look like Jason Mewes (aka Jay of Jay and Silent Bob)?
Re:I've always found the Bible series (Score:1)
As for the author, I wouldn't be surprised
Re:I've always found the Bible series (Score:2)
But some of the other 'Bible' titles that I purchased based on that good experience were right in line with your opinion, lacking is actually rather kind...
Re:I've always found the Bible series (Score:2)
Silly Bibles (Score:3, Interesting)
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.
Re:Silly Bibles (Score:1)
1) The old name was "IDG Books" not "CDG"
2) They didn't change their name, so much; they bought a pre-existing company and used the name. The pig already existed.
3) Your chronology is all wrong, and nothing especially changed when they bought Hungry Minds.
4) They publish many series of books, most of which don't include the word "Bible" in their titles. Several of their current series use the word "Visual" as a theme.
I stand corrected (Score:2)
Re:Silly Bibles (Score:1)
S
Oops. (Score:2)
for you (Score:1)
"Zope for you"
"PHP for you"
"Perl for you"
GNU/for you
Quick! (Score:2)
Hey (Score:1, Offtopic)
The Zope Book (Score:5, Informative)
It's released under the OPL [opencontent.org] and both an HTML version [zope.org] and a PDF version [zope.org] of the book are freely available.
Re:The Zope Book (Score:4, Informative)
While it is wonderful that it's free, the Zope Book suffers from a lack of understanding of where new Zope users start from. The outline concepts are reasonably well explained, but there's next to no code samples to show you how DTML works (think of the ORA camel and llama books by contrast). It's very much written by deep experts who haven't been able to think back to the learning paradigm.
Or, in other words, it's really not worth paying for a dead tree version.
Other Zope books such as the Zope Web Application Kit are nothing more than how to install CMF and other popular products if we've got time (actually, much of the Zope world is CMF obsessed - not all sites fit into the CMF community publishing model...)
If this book actually does what it says on the tin, it will be a welcome addition to the bookshelf.
Re:The Zope Book (Score:2)
Re:The Zope Book (Score:1)
How about "Zope on a Rope"?
I got The Zope Book (Score:2)
More a reference book I think.
Bible (Score:1)
not surprising (Score:2)
If it is called "bible" by users, it usually is.
Re:Zope and databases (Score:1)
ah, zope (Score:2, Informative)
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.
Re:ah, zope (Score:1)
If that wasn't bad enough, the ACS went towards an object model, proprietary markup language, and content management - just like Zope -
Just to clarify, Zope doesn't use a proprietary markup language and started with an object model.
Decent-but-spotty (Score:1, Flamebait)
I dunno, I thought the original bible had some interesting stories but was overall pretty spotty and even contradictory at times.
mark
Zope has a steep learning curve (Score:4, Informative)
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.
Re:Zope has a steep learning curve (Score:1)
Squishdot--A Slashcode clone (Score:2)
If you're looking to build a stripped-down slashdot-like site, Squishdot and Zope may be the answer.
Drwning in alphabet soup! (Score:3, Informative)
Re:Drwning in alphabet soup! (Score:1)
Informative woudd have been detials on what *exactly* the poster had troubles with, and what he or she was *trying* to do.
zope - when to use it (Score:2, Informative)
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!
Re:zope - when to use it (Score:1)
FreeZope (Score:1)
After 2 years of Zope (Score:1)
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.
an OO zealot's toy? (Score:1)
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.
Re:an OO zealot's toy? (Score:1)
I think HTML form interfaces are doomed anyhow. Businesses really want server-controlled GUI's; and HTML forms are optimized for e-brochures, not business forms.
Too many times in many businesses I have been asked to make web forms act like GUI's, with mixed results. The pressure is building. As soon as a decent protocol catches on (like SCGUI, plug plug), things like Zope will be reduced to e-brochure managers.