Zope 3 wiki → Documentation → HistoricalDocuments → DesignNotes →
last edited 5 years ago by stevea
created: 2003-08-03

ThroughTheWebDevelopmentInZope3

Through the web development in Zope 3

This document describes, at a high level, a vision for through-the-web (TTW) development in Zope 3.

There are two ways to do TTW development in Zope 3:

  • Active content
  • TTW Components

Active content

Active content is content that performs computation. It includes things like ZPT "pages" and Python and SQL "scripts".

The term "page" is used here rather than "template". A page is content in it's own right. It is not there to present some other object, although it may use bits of data from it's environment. Similarly the term "script" is used rather than "method" to connote stand-alone information that happens to be a program. Scripts do not provide behavior for other objects.

Scripts and pages may be acquired, however, their behavior doesn't depend on how they are accessed. The only place they can get data from is their container. (They can, of course, acquire information, using their container as a starting point.)

Active content is roughly equivalent to CGI programs or ASP pages. Active content provides a simple and familiar model for people coming from other systems. Active content also provides a somewhat familiar model for Zope 2 developers, although it is simpler and less powerful (by design) than similar facilities in Zope 2.

TTW Components

TTW Components provide a way to share software among multiple objects. Components are created in packages in service managers. Any normal folder can have a service manager associated with it. Every service manager contains a collection of packages, including a default package. Components are created in and configured from packages.

When we talk about creating components in a package, we are really talking about two things:

  • Creating component implementations
  • Creating component instances.

Some components, like adapters and views are transient and are not instantiated in a package but are instantiated when needed to adapt or present other components.

Other components, like services and utilities are instantiated and managed in packages. These components may be implemented in traditional file-based Python modules, or with through-the-web components.

When we talk about TTW component development, we are primarily talking about creating component implementations and configuration. Components will typically be implemented with TTW Python modules. TTW Python modules have the same syntax and semantics as regular Python modules, except that they are stored in the object database. TTW Python modules may be trusted or untrusted, depending on your site's policy. Through the use of file-syste, synchronization (see FileSystemSynchronizationProposal), they may also be developed and managed using file-system based tools. In fact, some sites might let TTW modules be trusted, but only allow editing of them on the file system.

The implementation of TTW views will also require the creation of ZPT (or DTML) templates. Templates will be connected to Python classes in TTW modules through configuration. It might be possible for TTW module code to access TTW templates. (This requires some research).

Just implementing TTW components doesn't make them useable alone. They must also be configured. There will be configuration objects that correspond directly to the configuration directives found in ZCML files. These directive objects will control how component implementations are used, what permissions they require, and how they are combined with templates.

Relation of TTW Components to CMF Tools and Skins

The CMF, provides a powerful model for separating persentation and business logic from content. There are two main mechanaisms for this:

  • CMF Tools provide centralized applications that all content share. In addition, tools often provide centralized registries for content configuration information or for components to be used with content.

    Zope 3 provides an identical feature called "services". Like other components, services may be implemented, instantiated, and managed TTW.

  • CMF Skins provide a place to put methods and templates that may be associated with content. The association is fairly loose between skin templates or methods and content and between skin templates or methods and other templates or methods. The association is by well-known method or template name, with some indirection through "actions" that map abstract operations on content to particular methods or templates in a skin.

    The name "skin" comes from the fact that alternate user interfaces, called "skins", typically only differing by look and feel, can be selected. The CMF skins tool manages skin methods and templates in folder-like objects called "layers". A skin is defined by specifying a search path as a sequence of layer names. When looking for a named method or template, the layers are searched in the specified order.

    Zope 3 provides separate facilities for application and presentation logic. Content-specific application logic is typically provided with adapters, which are registered in an adapter service.

    Presentation is provided via views, which are registered in view services. Views are registered in layers. As with the CMF, a skin is defined by a layer search path.

    There are a number of differences between Zope 3 skins and CMF skins:

    • In Zope 3, related method and templates are gathered into view components. This provides a more object-oriented development model and makes lookup and organization a bit simpler.
    • In Zope 3, components are looked up using an abstract name and a content type. This means that pages have simple names like "edit.html", rather than names that embed the content type names, like "news_edit.html". In addition to providing simpler names, the possibility for name conflicts is reduced.
    • Zope 3 layers only provide logical organization. Physical management of components is provided by packages. This greatly simplifies skin presentation and maintenance.

Aside from the differences noted above, the CMF and Zope 3 development models are quite similar.

paul (Oct 5, 2002 4:09 am; Comment #1)
Could you talk a little about the audience for ttw development? I'm primarily interested in whether this is for the Site Developer, and how much of Component Developer they will need to know to use this.

For instance, I saw that, to create a view, they have to know configuration. Will this suite of technologies be in reach for most Site Developers, or will it ultimately be Component Developers who want something quicker and in the ZODB that use ttw stuff?

I was very happy to see the comparison to cmf tools and skins. In particular the latter. I've been curious to see how the skin facility would map in Zope 3. I think, though, there are other aspects of the skin facility still unaddressed. If this is the right place to collect these aspects, then I'll suggest on zope-cmf that people come over here and comment about skins.

stevea (Oct 5, 2002 4:46 am; Comment #2)
Where do we defined the names of content types?

Are these the same as simple marker interfaces?



( 96 subscribers )