I agree with everything everyone said - especially Chris' whine on whining. I have been an unwitting participant in this. I also did not mean to imply anything sinister about Zope Corporation. I was merely ruminating/speculating to give an example of what people might commonly think the situation is, unless it is made clear. In any case, it is indicative of the maturity of the people on this list, that noone took my whiney rant as just a whiney rant - everyone actually gave it consideration. That is amazing and to be congratulated. Now I am committing to myself to re-write a sample chapter to see if I can actually do something about the documentation problem. I find my main complaints with the Zope book are that it uses a lot of things such as "examples", or "what have yous" in a lot of "quotes" which makes it, for example, such as, "hard to read!" Yackety Shmackety, right? I'm not slamming anyone's writing style - just looking for validation that I'm not the only one and that I'm on the right track. This may not be the place for it, but here's my re-write (all original with bits of the original text) of the first part of the "Object Orientation" chapter of the 2.6 book. -Patrick Price Object Orientation There are many programming languages based on Object Orientation (OO), and Zope is based on the Object-Oriented Programming (OOP) language known as Python. To understand and use Zope for creating anything but simple web sites, you must understand how OOP controls every behavior of Zope. Zope's foundation is built on object-orientation, so it follows that if you master OOP, you will master Zope. Object-orientation is a programming paradigm in which all logic (the actual programming and scripting) and data (folders, files, databases, etc. ) are treated as objects. Viewing everything you work with as an abstract object allows you to focus on a high-level view of your application, rather than getting bogged down with details like file descriptors, handles, and other low-level programming chores. You may think of objects as building blocks, which can be comprised of bundles of smaller things such as data, programs, variables - even other objects! By categorizing your data and logic - your problems - as objects, you will find that you can break up large problems into smaller problems, block by block. This level of abstraction helps you develop clear design solutions, perform rapid prototyping, and results in an efficient, well-structured application design. Objects Prior to the OOP paradigm, data was viewed as separate from program code, or sometimes mixed together without a clear delineation between them. Now, with OOP methodology, your data and logic can both be stored in a single object. Objects provide a clear and distinct separation of data and logic within themselves. Zope treats every thing as an object, whether it is, for example: a filesystem directory, a folder (container for other objects), files, modules, products, templates, forms, spreadsheets, spreadsheet cells, databases, database records, phone #'s, addresses, scripts, programs, calendars, buttons, URL's - Anything! There really is no limit to what can be called and modeled as an object. In your journey to understanding Zope's object-oriented framework, you may continue to think that data is just that - plain old data. You must leave those thoughts behind. Once anything - even a simple text file - is stored in Zope, it becomes an object. The associated details of the file, such as the file type, size, and location are stored along with it and become collectively known as the attributes of the object. Even the file data itself is considered an attribute of this newly-created file object. In the same manner a mere program becomes an object when it is stored in Zope. Programming, scripting, code, logic - are then referred to as the methods of the object. Thus, an object is comprised of attributes and methods.