Now that we have seen what a typical product may contain, we will install a product by downloading it from the Zope web site, unpack it within lib/python/Products and restart Zope. If all goes well, our newly installed product should then appear in our control panel screen. Moreover, we will be able to create new instances of this product anywhere we want in our web hierarchy.
For example, let's create a Slashdot clone using the Squishdot product for Zope. Our first task is to retrieve a copy of Squishdot from www.zope.org/Products. Squishdot is listed under the Feedback category, among others, and probably will be one of the first products listed. Click on the links that lead to a downloadable version of Squishdot; the latest version as of this writing is 1.3.0. Notice how even a product of moderate complexity is relatively small; the Squishdot version that I downloaded was a little more than 256KB.
To install Squishdot, we must unpack it into lib/python/Products. Assuming that we place newly downloaded files in /downloads, this means that we can unpack Squishdot in the following way:
# Set this to your Zope home export ZOPE=/usr/local/zope # Switch into the products directory cd $ZOPE/lib/python/Products # Unpack Squishdot into the current directory tar -zxvf /downloads/Squishdot-1-3-0.tar.gz
Older Zope products expect to be unpacked from the Zope root directory, rather than from within lib/python/Products. Unfortunately, there does not seem to be any obvious way to know how a product was packaged without looking at it:
tar -ztvf /downloads/ProductName.tar.gz
If each filename begins with the lib/python/Products pathname, then you will want to switch into $ZOPE, rather than $ZOPE/lib/python/Products, before unpacking the product.
Unpacking the archive is all we need to do in order to install Squishdot. However, Zope only looks for products when it starts up; we must restart the server before we can create instances of Squishdot on our system. The best way to do that is to click on the Restart button from within the control panel. Don't panic if your browser complains that the server is no longer running after you click on Restart, or if you see an obscure-looking Python exception backtrace after clicking on the Restart button. Rather, wait several seconds before clicking again on the control panel link in the left-hand frame, and it should work.
You can check to see if your product has been added by returning to the Product Management page within the control panel. If the newly installed product (Squishdot, in this case) does not appear on the list, double-check that it was unpacked correctly and that the permissions allow the Zope user access to the product's files.
At this point, we should be able to create a new Squishdot site by moving to the root (/) directory of the Zope server, selecting Squishdot site from the selection list and clicking on Add. This invokes the methods named in the constructors parameter to context.registerClass, invoked by the initialize function in Squishdot's __init__.py.
And indeed, we could move ahead and create our Squishdot site at this point. But Squishdot uses the Zope MailHost object (which represents an SMTP server) to send e-mail notifications. If you have not yet created and defined a MailHost, the Squishdot configuration screen will remind you to do so.
When Squishdot looks for a MailHost, it begins its search in the current directory. If it does not find a MailHost object, the search continues up the directory tree, stopping when Squishdot reaches / or when it finds a MailHost object. While this might appear to be a simple issue, it demonstrates the concept of acquisition, which is central to Zope. Moreover, it means that different Squishdot sites can send e-mail via different SMTP servers, simply by creating more than one MailHost object. Indeed, we can define a global default MailHost in /, overriding it as necessary by placing additional MailHost objects in subdirectories. The concept of acquisition permeates Zope and means that we can define or redefine nearly anything—MailHosts, users, headers and stylesheets—at a local level.
In this particular case, we will create an instance of MailHost in the / directory by choosing MailHost from the new product list and clicking on Add. Because a MailHost object represents an SMTP server, the configuration of this object is pretty straightforward, requiring that we enter the name of our Zope server's SMTP server. Most Linux machines run their own mail servers, so “localhost” is probably a reasonable value.
The mandatory ID field is used to identify this MailHost uniquely within the current directory, which is why Zope uses IDs to identify objects in URLs uniquely. Just as a filename is a unique identifier within a directory, a Zope object ID is a unique identifier within a folder or other object. The optional Title field is meant for humans, rather than for the underlying Zope server; if it is defined, an object's title is displayed from within the Zope server interface.
After you have created your MailHost object, you will be returned to the main Zope management screen for /. You should see your new MailHost object (represented with a small envelope icon), along with any title that you defined, in the list of objects.
We are now ready to create our Squishdot site. Add a new Squishdot site object using the selection list and Add button in the upper right-hand corner, choose an ID (i.e., URL pathname), optional title and mailhost, and then select some other basic parameters for your Squishdot site. For example, I chose an ID of atf and otherwise left the configuration options with their default values.
To enter my Squishdot site, I now tell my web browser to display http://localhost:8080/atf/. Zope receives this request for /atf and sees that we are referring to a Squishdot object. Zope then asks this object to display itself. Sure enough, we see an introductory screen that looks something like Slashdot but is powered by Zope.
We can create as many Squishdot sites as we might like, keeping in mind that every new site must have its own unique ID. In this way, we can set up one moderated site, one unmoderated site and another internal site for our organization's own uses—each with its own URL, potentially protected with its own set of users and groups.
To modify the Squishdot site, simply append /manage to the name of the object you want to modify, as in http://localhost:8080/atf/manage. This invokes Zope's management system on our Squishdot site. Using tabs at the top of the screen, you can modify nearly any parameter having to do with Squishdot, from moderation rules to the color of the text in which the site name is displayed.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Play for Me, Jarvis
- Non-Linux FOSS: .NET?
- Not So Dynamic Updates
- Designing Foils with XFLR5
- Users, Permissions and Multitenant Sites
- diff -u: What's New in Kernel Development