<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>The Zope 3 Component Architecture (Socket Example) — zope.component 4.4.1 documentation</title>
<link rel="stylesheet" href="_static/alabaster.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script type="text/javascript" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<script type="text/javascript" src="_static/language_data.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Events" href="event.html" />
<link rel="prev" title="Zope Component Architecture" href="narr.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="the-zope-3-component-architecture-socket-example">
<h1>The Zope 3 Component Architecture (Socket Example)<a class="headerlink" href="#the-zope-3-component-architecture-socket-example" title="Permalink to this headline">¶</a></h1>
<p>The component architecture provides an application framework that provides its
functionality through loosely-connected components. A <em>component</em> can be any
Python object and has a particular purpose associated with it. Thus, in a
component-based applications you have many small component in contrast to
classical object-oriented development, where you have a few big objects.</p>
<p>Components communicate via specific APIs, which are formally defined by
interfaces, which are provided by the <cite>zope.interface</cite> package. <em>Interfaces</em>
describe the methods and properties that a component is expected to
provide. They are also used as a primary mean to provide developer-level
documentation for the components. For more details about interfaces see
<cite>zope/interface/README.txt</cite>.</p>
<p>The two main types of components are <em>adapters</em> and <em>utilities</em>. They will be
discussed in detail later in this document. Both component types are managed
by the <em>site manager</em>, with which you can register and access these
components. However, most of the site manager’s functionality is hidden behind
the component architecture’s public API, which is documented in
<cite>IComponentArchitecture</cite>.</p>
<div class="section" id="adapters">
<h2>Adapters<a class="headerlink" href="#adapters" title="Permalink to this headline">¶</a></h2>
<p>Adapters are a well-established pattern. An <em>adapter</em> uses an object providing
one interface to produce an object that provides another interface. Here an
example: Imagine that you purchased an electric shaver in the US, and thus
you require the US socket type. You are now traveling in Germany, where another
socket style is used. You will need a device, an adapter, that converts from
the German to the US socket style.</p>
<p>The functionality of adapters is actually natively provided by the
<cite>zope.interface</cite> package and is thus well documented there. The <cite>human.txt</cite>
file provides a gentle introduction to adapters, whereby <cite>adapter.txt</cite> is
aimed at providing a comprehensive insight into adapters, but is too abstract
for many as an initial read. Thus, we will only explain adapters in the context
of the component architecture’s API.</p>
<p>So let’s say that we have a German socket:</p>
<p>and we want to convert it to an US socket</p>
<p>so that our shaver can be used in Germany. So we go to a German electronics
store to look for an adapter that we can plug in the wall:</p>
<p>Note that I could have called the passed in socket any way I like, but
<cite>context</cite> is the standard name accepted.</p>
<div class="section" id="single-adapters">
<h3>Single Adapters<a class="headerlink" href="#single-adapters" title="Permalink to this headline">¶</a></h3>
<p>Before we can use the adapter, we have to buy it and make it part of our
inventory. In the component architecture we do this by registering the adapter
with the framework, more specifically with the global site manager:</p>
<p><cite>zope.component</cite> is the component architecture API that is being
presented by this file. You registered an adapter from <cite>IGermanSocket</cite>
to <cite>IUSSocket</cite> having no name (thus the empty string).</p>
<p>Anyways, you finally get back to your hotel room and shave, since you have not
been able to shave in the plane. In the bathroom you discover a socket:</p>
<p>You now insert the adapter in the German socket</p>
<p>so that the socket now provides the US version:</p>
<p>Now you can insert your shaver and get on with your day.</p>
<p>After a week you travel for a couple of days to the Prague and you notice that
the Czech have yet another socket type:</p>
<p>You try to find an adapter for your shaver in your bag, but you fail, since
you do not have one:</p>
<p>or the more graceful way:</p>
<p>In the component architecture API any <cite>get*</cite> method will fail with a specific
exception, if a query failed, whereby methods starting with <cite>query*</cite> will
always return a <cite>default</cite> value after a failure.</p>
</div>
<div class="section" id="named-adapters">
<h3>Named Adapters<a class="headerlink" href="#named-adapters" title="Permalink to this headline">¶</a></h3>
<p>You are finally back in Germany. You also brought your DVD player and a couple
DVDs with you, which you would like to watch. Your shaver was able to convert
automatically from 110 volts to 240 volts, but your DVD player cannot. So you
have to buy another adapter that also handles converting the voltage and the
frequency of the AC current:</p>
<p>Now, we need a way to keep the two adapters apart. Thus we register them with
a name:</p>
<p>Now we simply look up the adapters using their labels (called <em>name</em>):</p>
<p>Clearly, we do not have an adapter for the MP3 player</p>
<p>but you could use the ‘dvd’ adapter in this case of course. ;)</p>
<p>Sometimes you want to know all adapters that are available. Let’s say you want
to know about all the adapters that convert a German to a US socket type:</p>
<p><code class="xref py py-func docutils literal notranslate"><span class="pre">zope.component.getAdapters()</span></code> returns a list of tuples. The first
entry of the tuple is the name of the adapter and the second is the
adapter itself.</p>
<p>Note that the names are always text strings, meaning <code class="docutils literal notranslate"><span class="pre">unicode</span></code> on
Python 2:</p>
</div>
<div class="section" id="multi-adapters">
<h3>Multi-Adapters<a class="headerlink" href="#multi-adapters" title="Permalink to this headline">¶</a></h3>
<p>After watching all the DVDs you brought at least twice, you get tired of them
and you want to listen to some music using your MP3 player. But darn, the MP3
player plug has a ground pin and all the adapters you have do not support
that:</p>
<p>So you go out another time to buy an adapter. This time, however, you do not
buy yet another adapter, but a piece that provides the grounding plug:</p>
<p>Then together they will provided a grounded us socket:</p>
<p>You now register the combination, so that you know you can create a
<cite>IUSGroundedSocket</cite>:</p>
<p>Given the grounder</p>
<p>and a German socket</p>
<p>we can now get a grounded US socket:</p>
<p>Of course, you do not have a ‘dvd’ grounded US socket available:</p>
<p>Again, you might want to read <cite>adapter.txt</cite> in <cite>zope.interface</cite> for a more
comprehensive coverage of multi-adapters.</p>
</div>
</div>
<div class="section" id="subscribers">
<h2>Subscribers<a class="headerlink" href="#subscribers" title="Permalink to this headline">¶</a></h2>
<p>While subscribers are directly supported by the adapter registry and are
adapters for all theoretical purposes, practically it might be better to think
of them as separate components. Subscribers are particularly useful for
events.</p>
<p>Let’s say one of our adapters overheated and caused a small fire:</p>
<p>We want to use all available objects to put out the fire:</p>
<p>Here some specific methods to put out the fire:</p>
<p>Now let use all these things to put out the fire:</p>
<p>If no subscribers are found for a particular object, then an empty list is
returned:</p>
</div>
<div class="section" id="utilities">
<h2>Utilities<a class="headerlink" href="#utilities" title="Permalink to this headline">¶</a></h2>
<p>Utilities are the second type of component, the component architecture
implements. <em>Utilities</em> are simply components that provide an interface. When
you register an utility, you always register an instance (in contrast to a
factory for adapters) since the initialization and setup process of a utility
might be complex and is not well defined. In some ways a utility is much more
fundamental than an adapter, because an adapter cannot be used without another
component, but a utility is always self-contained. I like to think of
utilities as the foundation of your application and adapters as components
extending beyond this foundation.</p>
<p>Back to our story…</p>
<p>After your vacation is over you fly back home to Tampa, Florida. But it is
August now, the middle of the Hurricane season. And, believe it or not, you are
worried that you will not be able to shave when the power goes out for several
days. (You just hate wet shavers.)</p>
<p>So you decide to go to your favorite hardware store and by a Diesel-powered
electric generator. The generator provides of course a US-style socket:</p>
<p>Like for adapters, we now have to add the newly-acquired generator to our
inventory by registering it as a utility:</p>
<p>We can now get the utility using</p>
<p>As you can see, it is very simple to register and retrieve utilities. If a
utility does not exist for a particular interface, such as the German socket,
then the lookup fails</p>
<p>or more gracefully when specifying a default value:</p>
<p>Note: The only difference between <cite>getUtility()</cite> and <cite>queryUtility()</cite> is the
fact that you can specify a default value for the latter function, so that it
will never cause a <cite>ComponentLookupError</cite>.</p>
<div class="section" id="named-utilities">
<h3>Named Utilities<a class="headerlink" href="#named-utilities" title="Permalink to this headline">¶</a></h3>
<p>It is often desirable to have several utilities providing the same interface
per site. This way you can implement any sort of registry using utilities. For
this reason, utilities – like adapters – can be named.</p>
<p>In the context of our story, we might want to do the following: You really do
not trust gas stations either. What if the roads are blocked after a hurricane
and the gas stations run out of oil. So you look for another renewable power
source. Then you think about solar panels! After a storm there is usually very
nice weather, so why not? Via the Web you order a set of 110V/120W solar
panels that provide a regular US-style socket as output:</p>
<p>Once it arrives, we add it to our inventory:</p>
<p>You can now access the solar panel using</p>
<p>Of course, if a utility is not available, then the lookup will simply fail</p>
<p>or more gracefully when specifying a default value:</p>
<p>Now you want to look at all the utilities you have for a particular kind. The
following API function will return a list of name/utility pairs:</p>
<p>Another method of looking up all utilities is by using
<cite>getAllUtilitiesRegisteredFor(iface)</cite>. This function will return an iterable
of utilities (without names); however, it will also return overridden
utilities. If you are not using multiple site managers, you will not actually
need this method.</p>
</div>
<div class="section" id="factories">
<h3>Factories<a class="headerlink" href="#factories" title="Permalink to this headline">¶</a></h3>
<p>A <em>factory</em> is a special kind of utility that exists to create other
components. A factory is always identified by a name. It also provides a title
and description and is able to tell the developer what interfaces the created
object will provide. The advantage of using a factory to create an object
instead of directly instantiating a class or executing any other callable is
that we can refer to the factory by name. As long as the name stays fixed, the
implementation of the callable can be renamed or moved without a breakage in
code.</p>
<p>Let’s say that our solar panel comes in parts and they have to be
assembled. This assembly would be done by a factory, so let’s create one for
the solar panel. To do this, we can use a standard implementation of the
<cite>IFactory</cite> interface:</p>
<p>Optionally, I could have also specified the interfaces that the created object
will provide, but the factory class is smart enough to determine the
implemented interface from the class. We now register the factory:</p>
<p>We can now get a list of interfaces the produced object will provide:</p>
<p>By the way, this is equivalent to</p>
<p>Of course you can also just create an object:</p>
<p>Note: Ignore the first argument (<cite>None</cite>) for now; it is the context of the
utility lookup, which is usually an optional argument, but cannot be in this
case, since all other arguments beside the <cite>name</cite> are passed in as arguments
to the specified callable.</p>
<p>Once you register several factories</p>
<p>you can also determine, which available factories will create objects
providing a certain interface:</p>
</div>
</div>
<div class="section" id="site-managers">
<h2>Site Managers<a class="headerlink" href="#site-managers" title="Permalink to this headline">¶</a></h2>
<p>Why do we need site managers? Why is the component architecture API not
sufficient? Some applications, including Zope 3, have a concept of
locations. It is often desirable to have different configurations for these
location; this can be done by overwriting existing or adding new component
registrations. Site managers in locations below the root location, should be
able to delegate requests to their parent locations. The root site manager is
commonly known as <em>global site manager</em>, since it is always available. You can
always get the global site manager using the API:</p>
<p>You can also lookup at site manager in a given context. The only requirement
is that the context can be adapted to a site manager. So let’s create a
special site manager:</p>
<p>Now we create a context that adapts to the site manager via the <cite>__conform__</cite>
method as specified in PEP 246.</p>
<p>We now instantiate the <cite>Context</cite> with our special site manager:</p>
<p>We can now ask for the site manager of this context:</p>
<p>The site manager instance <cite>lsm</cite> is formally known as a <em>local site manager</em> of
<cite>context</cite>.</p>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">zope.component</a></h1>
<h3>Navigation</h3>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="narr.html">Zope Component Architecture</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">The Zope 3 Component Architecture (Socket Example)</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#adapters">Adapters</a></li>
<li class="toctree-l2"><a class="reference internal" href="#subscribers">Subscribers</a></li>
<li class="toctree-l2"><a class="reference internal" href="#utilities">Utilities</a></li>
<li class="toctree-l2"><a class="reference internal" href="#site-managers">Site Managers</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="event.html">Events</a></li>
<li class="toctree-l1"><a class="reference internal" href="factory.html">Factories</a></li>
<li class="toctree-l1"><a class="reference internal" href="persistentregistry.html">Persistent Component Management</a></li>
<li class="toctree-l1"><a class="reference internal" href="zcml.html">ZCML directives</a></li>
<li class="toctree-l1"><a class="reference internal" href="configure.html">Package configuration</a></li>
<li class="toctree-l1"><a class="reference internal" href="hooks.html">The current component registry</a></li>
<li class="toctree-l1"><a class="reference internal" href="testlayer.html">Layers</a></li>
<li class="toctree-l1"><a class="reference internal" href="api.html"><code class="docutils literal notranslate"><span class="pre">zope.component</span></code> API Reference</a></li>
<li class="toctree-l1"><a class="reference internal" href="hacking.html">Hacking on <code class="docutils literal notranslate"><span class="pre">zope.component</span></code></a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="narr.html" title="previous chapter">Zope Component Architecture</a></li>
<li>Next: <a href="event.html" title="next chapter">Events</a></li>
</ul></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©Zope Foundation and Contributors.
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 1.8.3</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
|
<a href="_sources/socketexample.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>
distrib
>
Mageia
>
7
>
armv7hl
>
media
>
core-release
>
by-pkgid
>
16b6c7fca2fc9f56193b382cc05af140
>
files
>
210
