Catálogo de publicaciones - libros

By now you probably understand what Steve Alexander meant when he defined Zope as a platform that “manages complexity in gluing software components together”. Since we originally wrote the Recipe class in Chapter 5, we have not changed it at all, but look where we are now thanks to adapters!

In Chapter 7 and Chapter 8 we added through-the-web adding, editing, and displaying functionality to recipes by implementing appropriate browser pages. That was relatively easy to do because the adding and editing views are auto-generated and the displaying is handled by a Page Template. In this chapter, we will explore views in general. We will see how to write browser views that do not return HTML and how to write views for other HTTP protocols.

This chapter gives a bird’s eye view of Zope as an object publishing environment. It explains how Zope works as well as the principles of its Component Architecture. Make sure you understand the basic concepts explained here before moving on.

To start, you need to set up Zope on your computer. Firstly, we install Zope and its dependencies. Then we will set up one Zope instance which is a directory with Zope’s configuration, database files and extension modules. From this directory we will then start a Zope server.

We can now start with our example application. The website will store information about recipes from around the world. Thus the first thing we need is a component to store recipe information in. As we have discussed in Chapter 2, components that store data are content components. Before we are going to write such a component, we need to define what kind of data it shall store and provide: we need to write an interface!

Interfaces are contracts that define how components work together. They describe the methods and attributes provided by an object. Interfaces describe the of a component, they do not describe the . The modelling of interfaces can be tackled many different ways. As we look at these possibilities we will improve the example implementation with each iteration. This process of refactoring occurs a number of times in this book to constantly improve and adjust the code.

One of the major concepts behind Component Architecture is to divide different types of functionality into different components in order to keep the amount of functionality provided by a single component small. Its strength lies in combining these components into a powerful application. In Chapter 2, were defined as components that allow you to extend the functionality of existing components. Adapters play a role in Component Architecture and in Zope 3, the software based on it.

Adapters are useful when a component needs to work with a certain framework. Instead of requiring the objects the framework works with to provide a certain API, the framework usually tries to adapt the object to one of its own APIs. If an adapter exists for the object, then the framework can work with the object through the adapter. This chapter will demonstrate implementing adapters. Because adapters are an integral part of the Component Architecture, they will frequently appear in later chapters.

We have already worked with a framework using adapters: the Zope publisher. Views are named adapters that add presentation functionality to the objects they present.

In the previous chapters, we have seen what content objects can look like. You can store and provide data with getters and setters, or you can use the pythonic attribute approach. In either case, the values were stored inside the object instance. That means when the instance is gone, the data the instance is holding is gone, too. This is obviously not a practical approach. When we make a content component that is designed to store data over a period of time, we would like to be able to restart our application without losing that data. This chapter will show you how to do that.

How much functionality do the recipes have now? We can describe their API using interfaces and their data structure using schemas. We have a minimal implementation as a Python class which we have made persistent. Its instances can be stored in the ZODB. We can also add recipes to a Zope folder via the debug shell. That is all.

What we cannot do is display the data stored inside a recipe to a web browser. Our content component is only useful for interaction on a Python API level. What we need are components that allow recipes to do user interaction. Such components are adapters, more specifically views.

We are nearing the end of Part I. So far we have learned to describe a recipe’s data model, to make a persistent implementation and to display this data to a web browser. To bring the first part to its grand finale, we will a recipe’s data. The most common way to do that in a web environment is through browser forms.

The web is a multilingual and multicultural medium. Many websites and services offered over the web need to cope with users that have diverse language backgrounds. It is common for European websites to deal with four languages or more at a time. Even in countries like the United States, an increasing number of websites with nationwide audiences provide their content in Spanish as well as English.

Internationalization covers more than just adding another content language to a website. Time and dates are formatted differently in different countries, as well as numbers. Web applications need to be aware of the differences. Fortunately, Zope provides an excellent framework for internationalization () and localization () which is the subject of this chapter.

Our application lets us do quite a lot already with a small amount of code. We can add and edit recipes to the object database where they are persisted and later displayed to the visitor. It’s time to start thinking about the appearance of the overall application. Fortunately, Zope lets us worry about this independently of component code. That means we can delay the layout of the application for as long as we wish. We could hire a designer to do the layout for us, we only need to integrate the design into the application. This chapter shows you how to do that.