Personal tools
You are here: Home About Component architecture

Component architecture

Web applications, if they want to stay relevant over time, need to be extensible with new behavior, and it should be possible to override aspects of existing behavior as well.

When developing software, we like keeping the core of applications clean, and we like modularity. This gives us flexibility in the way we deploy applications. We want to be able to extend, or plug into, a core application from another package, without having to change the original application itself.

An example: take an application that provides some way for users to create and manage documents, like a blog or a CMS. In this application, a document is represented by a document content object. Now imagine that this application does what you need for one thing. This probably sounds familiar: this would be perfect if only it had this extra feature. Let's say what you want is a commenting feature. Let's also say that other people want to deploy the same application without this feature. And that some other people have an entirely different approach to commenting and don't like the way you want it to work. These requirements make it desirable that the application itself doesn't provide a commenting feature directly. It should however be possible to plug one in.

Grok provides patterns that allow you to extend the application from the outside. If you want to add a new commenting view (a new web page) to every document object in the application, the core application doesn't even need any preparation. This is just possible straight away with the way Grok works - just hook the view up to the document class from an extension. What want to take a special action when a document object gets added, like initializing the comment data structure? No need to modify the core application either: you can hook into the add event that the core application sends when an object is added to a container. How do you store the comments? Grok offers an annotation framework that allows you to cleanly add new data to an existing object, without the original object having to know about it. You can add arbitrarily complex data structures, as Grok comes with an object database out of the box. If you want to extend existing views, the core application does need some minimal preparation: it has to open a slot in its document template. Arbitrary extensions can then plug new sub-views into it, using viewlets.

We call these patterns the component architecture. The component architecture that Grok uses was created to allow developers to do extensibility in an uniform way. Instead of building endless ad-hoc pluggability and extension points into an application, we have one general, powerful Python library, zope.component, that helps us build these pluggability points. zope.component is in its foundations just a registry that helps you plug objects together, but it's a very powerful registry which allows some advanced patterns of glueing objects together. The Zope Toolkit libraries that Grok builds on use the component architecture, and thus you are dealing with a uniform, integrated story for pluggability when you work with any of these components.