I'm reading the awesome tutorial about the zope component architecture from:
http://www.muthukadan.net/docs/zca.html#adapters
I can't seem to understand the Adapters chapter.
>>> from zope.interface import implements
>>> from zope.component import adapts
>>> class FrontDeskNG(object):
...
... implements(IDesk)
... adapts(IGuest)
...
... def __init__(self, guest):
... self.guest = guest
...
... def register(self):
... guest = self.guest
... next_id = get_next_id()
... bookings_db[next_id] = {
... 'name': guest.name,
... 'place': guest.place,
... 'phone': guest.phone
... }
Correct me if I'm wrong. The above class FrontDeskNG is an adapter, right? As written in the article:
FrontDeskNG is an adapter of IDesk which adapts IGuest
Ok, so now I have the adapter, why would I have to register it to the GlobalSiteManager before I can use it?
I'm working on a mobile game backend and I want to make the code more modular by checking out Zope Component Architecture. I need the ability to swap out my storage with whatever database technology and have the code still work. This seemed like something ZCA proudly advertises. I have never read the famous GoF Design Patterns book, so please bear with me.
One pragmatic advantage is that it allows the following very cool snippet;
use_me_like_a_desk = IDesk(instance_of_something_providing_iguest)
You've not had to specify anything there apart from the fact you want something that provides the IDesk interface. As long as you've registered an adapter for converting IGuest to IDesk everything works.
This is probably the nicest example but there are a number of queries you can make using the registration framework. For example you can essential just ask;
I have this thing, please ensure that it has this interface.
or even in the case of utilities
Please give me the thing that provides this interface for my application
Often all the registration of the various adapters and utilities is done per application using zcml. This makes it easy as pie to swap out one adapter for another, or use a different implementation of a utility without having to change a ton of code.
More generally the registration of components reinforces decoupling. You can build multiple modules that work together without having to couple them together. The only things that two modules need to work together is a common set of interfaces.
This makes it incredibly easy to write modules that work seamlessly together without making them dependent on each other, which in turn makes it easy to add, remove, evolve and test new components without massive refactoring.
As I'm sure you've found out the various bits of zope documentation is spread out and difficult to find. It takes a long time I think for some of the concepts and the advantages they bring to click, the best thing you can do is read as much as you can and then go live in a cave for six months in Alaska and meditate on it.
The Comprehensive Guide to Zope Component Architecture is a good start but I also advise reading at least the zope.component docs and the zope.interface docs. In particular this example might help you understand the benefit