Now that we have started Zope, how do we use it? Well, the first and most important step is to fire up our web browser and point it to our computer, giving it the URL http://localhost:8080/. This displays some initial Zope information, including pointers to documentation and web sites.
Let's leave this introductory screen behind, moving instead to the main Zope management interface at http://localhost:8080/manage. You will be prompted to enter the username and password for a site manager; use the admin user and the password that the install script printed out when you first installed Zope.
Once you have entered the correct password, your browser window will be divided into two vertical frames: the left-hand side displays the hierarchy of your Zope server, while the right-hand side displays the details of the object you are currently viewing.
It's easy to understand what happens when you ask an Apache server for the document /foo/bar. Apache looks for a file named bar in the foo directory underneath its document root. If such a file exists, then Apache reads it from disk and returns its content in an HTTP response. If the file is a CGI program, then it executes the program and returns its output in an HTTP response. And if the file does not exist, Apache returns an error message to the user's browser.
Zope interprets URLs quite differently; the URL /foo/bar is interpreted as a request for Zope to invoke a display method on the bar object inside of the foo object. If either foo or bar does not exist, then Zope will return an error message indicating that no such object can be found in ZODB.
If we always had to worry about creating objects and writing display methods, then Zope would be a high-powered toy for programmers. Luckily for us, Zope lets us almost pretend that ZODB is a hierarchical filesystem into which we are placing our HTML files and graphics.
For example, we can create a simple HTML file using nothing more than our web browser. While inside of Zope's root folder (to which you can always return by clicking in the upper left-hand side of the browser's left frame), create a new document by choosing DTML Document from the “Select type to add...” selection list in the top right-hand corner. (As we will soon see, DTML—Document Template Markup Language—is Zope's superset of HTML; Zope almost always refers to DTML documents rather than HTML documents.)
Your web browser should now display a short HTML form with three elements:
The id text field. Every object in Zope has an ID, and IDs must be unique within a folder. IDs are analogous to filenames on a disk, and they are used to identify objects within a URL. In the URL /foo/bar, foo is the ID of a folder object, while bar is the ID of an object within that folder. Zope documents traditionally don't have suffixes (e.g., .html and .gif); because the system knows what type of object is associated with each ID, such a suffix would be redundant.
The title text field. The object's ID appears in URLs, but the object's title appears in all of the internal Zope management screens. (The object's title has nothing to do with the HTML <title> tag, which you still will have to create.)
The file element allows you to upload a file from your local computer using HTTP uploads. This means that you can create a DTML file on your local computer and upload it to Zope when you are ready for testing.
For the purposes of this example, we will enter an ID of testdoc, and a title of “Test document”. While we simply could add this document to ZODB, that would leave it empty. Thus, we will click on the “Add and edit” button, which gives us a text area with some default content:
<dtml-var standard_html_header> <h2><dtml-var title_or_id></h2> <p> This is the <dtml-var id> Document. </p> <dtml-var standard_html_footer>
You can edit the contents however you want within this text area. When you have finished, click on the save changes button at the bottom of the screen. This button brings you back to the editing window but adds a reminder indicating when the document was last modified.
Our DTML document looks very much like HTML, except that it includes several tags that begin with <dtml-var>. DTML is actually a programming language that lets you do all sorts of things, but it is probably easiest (and best) to think of it as a very strong server-side include mechanism. As demonstrated in this sample document, <dtml-var> lets you insert dynamic values into the current document. Thus <dtml-var standard_html_header> inserts the contents of the object with the ID of standard_html_header, while <dtml-var id> inserts the ID of the current document. As you can imagine, <dtml-var title_or_id> displays either the title or the ID, depending on whether a title has been defined.
When Zope encounters the expression <dtml-var standard_html_header>, it looks in the current folder for an object with the ID standard_html_header. If such an object exists, then the <dtml-var> tag is replaced with the object's viewable contents. If no such object exists, then Zope repeats its search in the enclosing folder. In this way, Zope works its way up the entire hierarchy until it reaches the root folder.
This means that automatically inserted headers and footers depend not only on our <dtml-var> tags, but also on the location of our DTML document. The notion that an object's location in the object hierarchy affects its output is known as acquisition in the Zope world, and it is both important and useful. Using acquisition, you can have a different set of headers and footers for each folder. Moving a document from one folder to another changes the search path that Zope uses when looking for headers, footers and other objects. The behavior of an object in Zope thus depends not only on its definition, but also on its location in the object hierarchy. For this reason, acquisition is sometimes explained as analogous to the “nature vs. nurture” debate in biology: an object's definition can be seen as “nature”, while its location in the object hierarchy can be seen as “nurture”.
To view the current contents of the document, click on the view tab at the top of the frame. You will see the document's contents exactly as a user would want. To edit the document once again, I find it easiest to click on the “Root folder” link in the top-left corner, select the testdoc object and then edit things once more using the text area.
If you make a mistake while editing a DTML document, you will be happy to know that Zope provides infinite undo. Click on the undo tab on the top right of the DTML editing screen, and select the version to which you want to return. Infinite undo is one of my favorite features in Zope, not only because it allows me to undo my mistakes, but because it's so easily accessible to nonprogrammers, and it works with any kind of object on the system.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide