Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
ZCA: A component architecture for Python
1. A Component Architecture for Python
Timo Stollenwerk
February 26th, 2009
Timo Stollenwerk A Component Architecture for Python
2. Introduction
Developing a large software system is always very complicated
How to avoid starting from the scratch over and over again?
How to reuse, customize and extend existing functionality?
Timo Stollenwerk A Component Architecture for Python
3. Object-orientation
Object-orientation provides two approaches
Subclassing
Delegation
Timo Stollenwerk A Component Architecture for Python
4. Subclassing
A subclass can be derived from one or more superclasses
Inherits all of their functionality
Unless explicitly overridden
Weakness: A new class for every change in functionality
Common in Zope 2
Timo Stollenwerk A Component Architecture for Python
5. Delegation
Instead of inheriting functionality from a superclass
Delegate the work among several separate objects called
components
Each component takes responsibility in a complex action
Example: Model-View-Controller
When a component is no longer satisfactory, it can be replaced
by a better implementation
Timo Stollenwerk A Component Architecture for Python
6. A Python Framework for component based design
The Zope Component Architecture (ZCA):
A Python framework for supporting component based design
and programming
Well suited to developing large Python software systems
Not specic to the Zope web application server
Python Component Architecture
Timo Stollenwerk A Component Architecture for Python
7. A Python Framework for component based design
There are two core packages related to the ZCA:
zope.interface is used to dene the interface of a component
zope.component deals with registration and retrieval of
components
Timo Stollenwerk A Component Architecture for Python
8. Interfaces
Gang of Four: Program to an interface, not an implementation
Legal contract
Vendor has to fulll its promises
Customer uses the contract as a guarantee
Both know, from the contract, what is expected from the
transaction
Interfaces can server as API documentation
Python has no build-in support for interfaces
Timo Stollenwerk A Component Architecture for Python
9. Installation
$ e a s y _ i n s t a l l zope . i n t e r f a c e
$ e a s y _ i n s t a l l zope . component
Timo Stollenwerk A Component Architecture for Python
10. Interface Example
from zope . i n t e r f a c e i m p o r t ∗
c l a s s IQuacksLikeADuck ( I n t e r f a c e ) :
... d e f quack ( ) :
... R e t u r n s a q u a c k i n g sound .
...
c l a s s P l a t y p u s ( o b j e c t ) :
... i m p l e m e n t s ( IQuacksLikeADuck )
...
... d e f quack ( s e l f ) :
... r e t u r n Quack !
...
ben = P l a t y p u s ( )
IQuacksLikeADuck . p r o v i d e d B y ( ben )
True
p r i n t ben . quack ( )
Quack !
Timo Stollenwerk A Component Architecture for Python
11. The Standard Python Way
i f h a s a t t r ( ben , ' quack ' ) :
... ben . quack ( )
Zope 2 is littered with skeletons like if getattr(obj,
'_isPrincipiaFolderish', 0)
Where does that get documented?
Who knows it's there?
Who knows what its values may be.
Is it callable?
Interfaces allow one to formalize duck typing, without really
adding too much weight to their program.
Timo Stollenwerk A Component Architecture for Python
12. Adaption
c l a s s Hunter ( o b j e c t ) :
... d e f __init__ ( s e l f , name ) :
... s e l f . name = name
...
tom = Hunter ( 'Tom ' )
IQuacksLikeADuck . p r o v i d e d B y ( tom )
False
Timo Stollenwerk A Component Architecture for Python
13. A DuckCall Adapter
from zope . component i m p o r t a d a p t s
c l a s s D u c k C a l l ( o b j e c t ) :
... i m p l e m e n t s ( IQuacksLikeADuck )
... a d a p t s ( Hunter )
...
... d e f __init__ ( s e l f , h u n t e r ) :
... # Adapters are passed in t h e i r
... # a d a p t e e a s f i r s t argument
... s e l f . hunter = hunter
...
... d e f quack ( s e l f ) :
... r e t u r n s e l f . h u n t e r . name + ' q u a c k s w i t h
...
zope . component . p r o v i d e A d a p t e r ( D u c k C a l l )
Timo Stollenwerk A Component Architecture for Python
14. A Tickler
d e f t i c k l e r ( ∗ a r g s ) :
... Goes t h r o u g h t h e p r o v i d e d ar gu me nt s and
t r i e s t o make them quack
... for potentialQuacker in args :
... q u a c k e r = IQuacksLikeADuck ( p o t e n t i a l Q u a c k e r ,
... None )
... i f q u a c k e r i s None :
... p r i n t Could not quack : %r % p o t e n t i a l Q u a
... else :
... p r i n t q u a c k e r . quack ( )
Timo Stollenwerk A Component Architecture for Python
15. A Tickler (2)
t i c k l e r ( ben , tom , s q u e e k e r s )
Quack !
Tom q u a c k s w i t h a duck c a l l
Could not quack : __main__ . I r i s h W o l f h o u n d o b j e c t a t
Timo Stollenwerk A Component Architecture for Python
16. Summary
This was a very simple example with Interfaces and Adapters
But it's a powerful building block
Everything ows through interfaces and adapter registries
There is more: content components, multiadapters, utilities, ...
Timo Stollenwerk A Component Architecture for Python
17. Further Information
A Comprehensive Guide to Zope Component Architecture
(Baiju M)
Web Component Development with Zope 3 (P. von
Weitershausen)
Zope 3 Wiki (http://wiki.zope.org/zope3)
Timo Stollenwerk A Component Architecture for Python
18. The End
The End
Timo Stollenwerk A Component Architecture for Python