Catálogo de publicaciones - libros

Compartir en
redes sociales


Web Component Development with Zope 3

Philipp von Weitershausen

Second Revised and Enlarged Edition.

Resumen/Descripción – provisto por la editorial

No disponible.

Palabras clave – provistas por la editorial

Operating Systems; Software Engineering/Programming and Operating Systems; Information Systems Applications (incl. Internet)

Disponibilidad
Institución detectada Año de publicación Navegá Descargá Solicitá
No detectada 2007 SpringerLink

Información

Tipo de recurso:

libros

ISBN impreso

978-3-540-33807-9

ISBN electrónico

978-3-540-33808-6

Editor responsable

Springer Nature

País de edición

Reino Unido

Fecha de publicación

Información sobre derechos de publicación

© Springer-Verlag Berlin Heidelberg 2007

Tabla de contenidos

Adapters

Philipp von Weitershausen

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.

Part II - Intermediate | Pp. 193-206

Automated Testing

Philipp von Weitershausen

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.

Part II - Intermediate | Pp. 207-232

Advanced Views

Philipp von Weitershausen

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.

Part II - Intermediate | Pp. 233-254

Metadata

Philipp von Weitershausen

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 , also plays an important role. Common examples of metadata include:

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

Part II - Intermediate | Pp. 255-277

Containers

Philipp von Weitershausen

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 . 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.

Part II - Intermediate | Pp. 279-301

Events

Philipp von Weitershausen

A key concept of the Component Architecture is . 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.

Part II - Intermediate | Pp. 303-327

Sources and Vocabularies

Philipp von Weitershausen

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.

Part III - Expert | Pp. 331-343

Sites

Philipp von Weitershausen

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 .

Part III - Expert | Pp. 345-358

Indexing and Searching

Philipp von Weitershausen

In previous chapters we have substantially extended the 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 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.

Part III - Expert | Pp. 359-375

Browser Sessions

Philipp von Weitershausen

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 . 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.

Part III - Expert | Pp. 377-387