nach oben

2007 | Buch

Web Component Development with Zope 3

verfasst von: Philipp von Weitershausen

Verlag: Springer Berlin Heidelberg

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

Where Zope leads, Python follows. So it has been for a decade, and the trend doesn’t show any signs of st- ping. Whatever the latest buzzword—be it RESTful web programming, st- dardized interfaces, pluggable components, or practical restricted-execution environments, Zope has quietly led the way, delivering the goods years ahead of anyone else. Not just as technology concepts, but shipped and working in paying clients’ o?ces. And yet, strangely, Zope’s role in the ongoing development of Python is little-known and little-appreciated among Python developers. It is f- quently the case that some new and much-touted development in the Python community—especially in the web application and object security arenas—is something that Zope has already been doing for many years. I’m somewhat ba?ed by this peculiar blind spot in the Python com- nity. Even when I tell people that Zope’s already done something that they’re working on, the response is usually a blank look, or no response at all. It’s almost as if the innovations of Zope don’t really exist until somebody else reinvents them. In fact, the pattern has led me coin this little saying: Those who do not study Zope, are condemned to reinvent it. It doesn’t matter if you don’t plan to actually use Zope. Frankly, I haven’t used Zope in years. But the lessons I learned from Zope, I use constantly. Studying Zope—Zope 3 in particular—will make you a better programmer, without question.

Inhaltsverzeichnis

Frontmatter

Beginner

Frontmatter

1. Introduction

2. Zope and the Component Architecture

Abstract

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.

3. Installing Zope

Abstract

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.

4. Interfaces

Abstract

We can now start with our example application. The World Cookery 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 what of a component, they do not describe the how. 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.

5. Content Components

6. Persistency

Abstract

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.

7. Simple Views and Browser Pages

Abstract

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.

8. Browser Forms

Abstract

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 modify a recipe’s data. The most common way to do that in a web environment is through browser forms.

Intermediate

Frontmatter

9. Internationalization

Abstract

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 (i18n) and localization (l10n)¹ which is the subject of this chapter.

10. Customizing a Site’s Layout

Abstract

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.

11. Adapters

Abstract

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, adapters were defined as components that allow you to extend the functionality of existing components. Adapters play a major 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.

12. Automated Testing

Abstract

In the introduction, Zope was advertised as a product that makes it easy to do Quality Assurance. So far, we have not done much to demonstrate that. That is mostly because we were busy exploring the Component Architecture. Now it is time to start thinking about measures that ensure not only a good development process but also a high-quality software product.

13. Advanced Views

Abstract

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.

14. Metadata

Abstract

An important aspect of many web applications, especially content management systems (CMS), is the storage of primary data. However the extra or secondary data associated with objects, generally called metadata, also plays an important role. Common examples of metadata include:

information about the creator, author, or editor of a document,
time and date of the creation or last modification of an object,
state of a document in an organizational workflow.

Zope handles metadata very well and supports important standards out-of- the-box. We will see how to use them in this chapter.

15. Containers

Abstract

When we created recipes with the web interface, we simply added them to the database root, the root folder. Folders are special content components because they contain other content components. They are content containers. Containment is an important concept in Zope and containers are important components. They occur everywhere, not only where content components are involved.

After introducing the basic concepts and necessary interfaces, this chapter explains common uses of containers, such as containment constraints and names of contained objects.

16. Events

Abstract

A key concept of the Component Architecture is events. In many applications, it is necessary to trigger certain operations in particular circumstances. Zope provides a flexible and efficient event system that makes the implementation of such event-triggered components as well as the triggering itself very easy.

Expert

Frontmatter

17. Sources and Vocabularies

Abstract

In Chapter 4, we introduced a variant of interfaces that allow easy data modelling: schemas. Schemas are composed of fields which describe constraints on certain data values, such as the type, the length, size or range of the value stored. In this chapter we will learn about another constraint: value sets.

18. Sites

Abstract

In many content management applications, hierarchical structures play an important role for organizing content. Content structures like these can easily be modelled in Zope using the location and containment concepts we covered in Chapter 15. Zope not only allows you to put content in such structures, it also allows you to locally customize component registrations in sites.

19. Indexing and Searching

Abstract

In previous chapters we have substantially extended the World Cookery application. The application is ready for hobby cooks from around the world to add their favourite recipes, but what about visitors who might be looking for a specific recipe? There is currently no easy way for visitors to search for recipes. The World Cookery application definitely needs a search feature.

This chapter looks at Zope’s indexing and searching capabilities plus some facilities that help us work with persistent objects.

20. Browser Sessions

Abstract

In HTTP, the only way clients can interact with a server is through individual actions called requests. The web application cannot make any assumption about when or whether the client will send the next request or what that next request will entail. This makes HTTP a state-less protocol. A common technique to associate state on the server with HTTP clients are sessions. They are a pattern implemented by many web application servers in which arbitrary data that persists from request to request is associated with a client, independent of any user authorization. Zope provides flexible components to support this pattern.

21. Security

Abstract

This chapter gives you a look at Zope’s security architecture. Security is crucial to most web applications, especially when they are exposed to the Internet. This discussion has been postponed until now for two reasons. Firstly, we wanted to get started on the example application without having to worry too much about security initially. Secondly, understanding the security system requires an understanding of how Zope itself works. For example, understanding the concept of a trusted adapter requires an understanding of the fundamental concept of an adapter.

22. Authentication and User Management

Abstract

In the last chapter we discussed how users (known as principals) interact with Zope’s security system. In this chapter we look at how users are authenticated.

23. Debugging Zope

Abstract

No software is bug-free. In fact, a great part of a software developer’s time is spent finding and fixing bugs. The more complicated a system gets, the more complicated it usually is to find and fix bugs. Fortunately, Zope provides tools to help you debug Zope-based applications. They are introduced in this chapter.

24. Packaging and Deployment

Abstract

Our global community web application for hobbyist cooks is now complete. In earlier chapters we built a website for sharing and storing recipes. The web application also now supports several Internet protocols, data formats and authentication schemes. This chapter looks at packaging the application and deploying it on a production server.

Backmatter

Titel: Web Component Development with Zope 3
verfasst von: Philipp von Weitershausen
Verlag: Springer Berlin Heidelberg
Electronic ISBN: 978-3-540-33808-6
Print ISBN: 978-3-540-33807-9
DOI: https://doi.org/10.1007/978-3-540-33808-6