Zope QuickStart

Welcome to Zope - a new generation of software that we call a web application platform. Like web application servers, Zope provides very high performance and a strong framework for dynamic applications.

This QuickStart is built with Zope objects -- take a look!

Zope, though, is distinguished by its integrated object database which, when combined with a revolutionary object model, provides a completely unique facility for servicing content managers and web application developers. This outline, implemented in Zope, talks about the various strengths of the Zope platform and some of the other products available for it.

Start working in the management screens

+ Database Integration
+ Content Management
+ Application Development
- Web to Objects
+ Integrated Object Database
- Data Sharing

Problem: You have a common footer that you want on every page in your site. Well, not every page. There's one folder that needs a slightly different footer, but only that folder and its subfolders need it. Another problem: in that footer you want to have a feedback button to send email to someone about the site, but that someone can change and may need to be different in certain folders, and go unaffected in others. Solution: Acquisition!

Think of Acquisition as a sort of run-time inheritence (for the object savvy). Another way of looking at it is Environmental inheritence. When you're at work, your phone number is different than your phone number at home. You're the same person in both places, but your phone number changes depending on where you are. You acquire it from your environment. Acquisition is the same thing. Let's show how this is being used in the Objects section of this QuickStart.

Data Sharing Tree

You'll notice that every item in this tree that expands into content is indented in the tree properly and closes with a horizontal rule. While every document could have had a closing <HR> added at the end of it by hand, what if suddenly we decided to change the width of the rule or set it to noshade? Or even wanted to change with a different element such as an image? We'd have to go into and change each document by hand. Unacceptable. Instead, we use Acquisition. In the Outline (1) folder there is a document dtcTemplate. dtcTemplate is used to render the content sections (also known as leaves) of the tree you're viewing. The actual contents of the leaves are defined much further below. This section is defined in DataSharing (2), and is being rendered using dtcTemplate. But how is this possible if dtcTemplate is not in the DataSharing folder? Because of Acquisition, DataSharing acquires dtcTemplate from its parent (Objects) who acquires it from its parent (Outline). But because of Acquisition, dtcTemplate appears to be (and acts) like a regular member object of DataSharing.

So if that's the case, why do all of the leaves in object have a similar style but different content? The DTML source code for the dtcTemplate document is as follows:

<!--#var standard_html_header-->
<!--#var dtContent-->
<!--#var standard_html_footer-->

The dtContent is a DTML document inside of each subfolder that gets inserted into the dtcTemplate document. Again, each leaf appears different because the dtContent is specified at the leaf level here, while keeping a similar identity because the dtcTemplate document that is being called to render each leaf is shared across all of the leaf subfolders. When we started working on this QuickStart project, a dtContent document was defined in the top folder that is being used for the entire QuickStart tree that you are now reading so that all of the leaves would render a simple document until a real dtcTemplate was defined for their level. Meaning: all of the empty folders acquired the default document from higher up until it got overridden.

+ Managed Through the Web
+ Direct URL Access to Objects
+ Security
+ Sessions
+ Undo