I have started using Zope interfaces in my code, and as of now, they are really only documentation. I use them to specify what attributes the class should possess, explicitly implement them in the appropriate classes and explicitly check for them where I expect one. This is fine, but I would like them to do more if possible, such as actually verify that the class has implemented the interface, instead of just verifying that I have said that the class implements the interface. I have read the zope wiki a couple of times, but still cannot see much more use for interfaces than what I am currently doing. So, my question is what else can you use these interfaces for, and how do you use them for more.
Where I work, we use Interfaces so that we can use ZCA, or the Zope Component Architecture, which is a whole framework for making components that are swappable and pluggable using Interface
s. We use ZCA so that we can cope with all manner of per-client customisations without necessarily having to fork our software or have all of the many per-client bits messing up the main tree. The Zope wiki is often quite incomplete, unfortunately. There's a good-but-terse explanation of most of ZCA's features on its ZCA's pypi page.
I don't use Interface
s for anything like checking that a class implements all the methods for a given Interface
. In theory, that might be useful when you add another method to an interface, to check that you've remembered to add the new method to all of the classes that implement the interface. Personally I strongly prefer to create a new Interface
over modifying an old one. Modifying old Interfaces
is usually a very bad idea once they're in eggs that have been released to pypi or to the rest of your organisation.
A quick note on terminology: classes implement Interface
s, and objects (instances of classes) provide Interface
s. If you want to check for an Interface
, you would either write ISomething.implementedBy(SomeClass)
or ISomething.providedBy(some_object)
.
So, down to examples of where ZCA is useful. Let's pretend that we're writing a blog, using the ZCA to make it modular. We'll have a BlogPost
object for each post, which will provide an IBlogPost
interface, all defined in our handy-dandy my.blog
egg. We'll also store the blog's configuration in BlogConfiguration
objects which provide IBlogConfiguration
. Using this as a starting point, we can implement new features without necessarily having to touch my.blog
at all.
The following is a list of examples of things that we can do by using ZCA, without having to alter the base my.blog
egg. I or my co-workers have done all of these things (and found them useful) on real for-client projects, though we weren't implementing blogs at the time. :) Some of the use cases here could be better solved by other means, such as a print CSS file.
Adding extra views (BrowserView
s, usually registered in ZCML with the browser:page
directive) to all objects which provide IBlogPost
. I could make a my.blog.printable
egg. That egg would register a BrowserView called print
for IBlogPost
, which renders the blog post through a Zope Page Template designed to produce HTML that prints nicely. That BrowserView
would then appear at the URL /path/to/blogpost/@@print
.
The event subscription mechanism in Zope. Say I want to publish RSS feeds, and I want to generate them in advance rather than on request. I could create a my.blog.rss
egg. In that egg, I'd register a subscriber for events that provide IObjectModified (zope.lifecycleevent.interfaces.IObjectModified
), on objects that provide IBlogPost
. That subscriber would get get called every time an attribute changed on anything providing IBlogPost
, and I could use it to update all the RSS feeds that the blog post should appear in.
In this case, it might be better to have an IBlogPostModified
event that is sent at the end of each of the BrowserView
s that modify blog posts, since IObjectModified
gets sent once on every single attribute change - which might be too often for performance's sake.
Adapters. Adapters are effectively "casts" from one Interface to another. For programming language geeks: Zope adapters implement "open" multiple-dispatch in Python (by "open" I mean "you can add more cases from any egg"), with more-specific interface matches taking priority over less-specific matches (Interface
classes can be subclasses of one another, and this does exactly what you'd hope it would do.)
Adapters from one Interface
can be called with a very nice syntax, ISomething(object_to_adapt)
, or can be looked up via the function zope.component.getAdapter
. Adapters from multiple Interface
s have to be looked up via the function zope.component.getMultiAdapter
, which is slightly less pretty.
You can have more than one adapter for a given set of Interface
s, differentiated by a string name
that you provide when registering the adapter. The name defaults to ""
. For example, BrowserView
s are actually adapters that adapt from the interface that they're registered on and an interface that the HTTPRequest class implements. You can also look up all of the adapters that are registered from one sequence of Interface
s to another Interface
, using zope.component.getAdapters( (IAdaptFrom,), IAdaptTo )
, which returns a sequence of (name, adapter) pairs. This can be used as a very nice way to provide hooks for plugins to attach themselves to.
Say I wanted to save all my blog's posts and configuration as one big XML file. I create a my.blog.xmldump
egg which defines an IXMLSegment
, and registers an adapter from IBlogPost
to IXMLSegment
and an adapter from IBlogConfiguration
to IXMLSegment
. I can now call whichever adapter is appropriate for some object I want to serialize by writing IXMLSegment(object_to_serialize)
.
I could even add more adapters from various other things to IXMLSegment
from eggs other than my.blog.xmldump
. ZCML has a feature where it can run a particular directive if and only if some egg is installed. I could use this to have my.blog.rss
register an adapter from IRSSFeed
to IXMLSegment
iff my.blog.xmldump
happens to be installed, without making my.blog.rss
depend on my.blog.xmldump
.
Viewlet
s are like little BrowserView
s that you can have 'subscribe' to a particular spot inside a page. I can't remember all the details right now but these are very good for things like plugins that you want to appear in a sidebar.
I can't remember offhand whether they're part of base Zope or Plone. I would recommend against using Plone unless the problem that you are trying to solve actually needs a real CMS, since it's a big and complicated piece of software and it tends to be kinda slow.
You don't necessarily actually need Viewlet
s anyway, since BrowserView
s can call one another, either by using 'object/@@some_browser_view' in a TAL expression, or by using queryMultiAdapter( (ISomething, IHttpRequest), name='some_browser_view' )
, but they're pretty nice regardless.
Marker Interface
s. A marker Interface
is an Interface
that provides no methods and no attributes. You can add a marker Interface
any object at runtime using ISomething.alsoProvidedBy
. This allows you to, for example, alter which adapters will get used on a particular object and which BrowserView
s will be defined on it.
I apologise that I haven't gone into enough detail to be able to implement each of these examples straight away, but they'd take approximately a blog post each.