Zope Component Architecture - Revision history

Drobbins: /* Interfaces */

2012-02-14T15:53:29Z

‎Interfaces

Drobbins: /* ZCML */

2012-02-14T15:52:26Z

‎ZCML

216.31.88.193: /* The Parts of ZCA */

2012-02-03T06:23:25Z

‎The Parts of ZCA

216.31.88.193: /* ZCML */

2012-02-03T05:54:15Z

‎ZCML

216.31.88.193: /* ZCML */

2012-02-03T01:08:51Z

‎ZCML

216.31.88.193: /* ZCML */

2012-02-03T01:02:56Z

‎ZCML

216.31.88.193 at 01:01, 3 February 2012

2012-02-03T01:01:17Z

Drobbins at 17:34, 2 February 2012

2012-02-02T17:34:31Z

Drobbins: /* The Parts of ZCA */

2012-02-02T17:15:34Z

‎The Parts of ZCA

Drobbins: /* The Parts of ZCA */

2012-02-02T17:13:28Z

‎The Parts of ZCA

← Older revision		Revision as of 15:53, 14 February 2012
Line 28:		Line 28:

	At least now you know what ZCA is designed for, so you will be able to evaluate it fairly :)		At least now you know what ZCA is designed for, so you will be able to evaluate it fairly :)
		+
		+	Martin Aspeli has written [http://www.martinaspeli.net/articles/of-babies-and-bathwater-or-why-i-love-the-zope-component-architecture a defense of ZCA].

	== The Parts of ZCA ==		== The Parts of ZCA ==

@@ Line 63: / Line 63: @@
 </configure>
 </pre>
 [[Category:Zope]]
 [[Category:Developer]]
 [[Category:Featured]]

@@ Line 31: / Line 31: @@
 == The Parts of ZCA ==
-This section describes the "components" of ZCA itself. One of the most complicated things about ZCA is the new terminology that it uses for its various parts. Once you understand this terminology, ZCA is a lot more approachable.
+This section describes the "components" of ZCA itself. One of the most complicated things about ZCA is the new terminology that it uses for its various parts. Once you understand this terminology, ZCA is a lot more approachable. Also see [http://wiki.zope.org/zope3/ComponentArchitectureOverview]
 ; Components: A component is Python-based code, usually a class, that implements an ''Interface'' (defined below.)

@@ Line 54: / Line 54: @@
 For now, read the [http://codespeak.net/z3/five/manual.html Five Manual] and work through the <tt>[http://svn.zope.org/z3/Five/trunk/demo/?rev=46891#dirlist demos]</tt> directory.
 [[Category:Zope]]
 [[Category:Developer]]
 [[Category:Featured]]

@@ Line 53: / Line 53: @@
 The official specification for ZCML is viewable in the [http://apidoc.zope.org/++apidoc++/ Zope 3 APIDoc site], although this may not accurately reflect the API in Zope 2.13. In terms of explanatory, conceptual documentation, there does not seem to be anything good available, and this section will attempt to fill that gap.
-For now, read the [http://codespeak.net/z3/five/manual.html Five Manual], grab the Five source code, and work through the <tt>demos</tt> directory.
+For now, read the [http://codespeak.net/z3/five/manual.html Five Manual] and work through the <tt>[http://svn.zope.org/z3/Five/trunk/demo/?rev=46891#dirlist demos]</tt> directory.
 [[Category:Zope]]
 [[Category:Developer]]
 [[Category:Featured]]

@@ Line 51: / Line 51: @@
 == ZCML ==
-The official specification for ZCML is viewable in the [http://apidoc.zope.org/++apidoc++/ Zope 3 APIDoc site]. In terms of explanatory, conceptual documentation, there does not seem to be anything good available, and this section will attempt to fill that gap.
+The official specification for ZCML is viewable in the [http://apidoc.zope.org/++apidoc++/ Zope 3 APIDoc site], although this may not accurately reflect the API in Zope 2.13. In terms of explanatory, conceptual documentation, there does not seem to be anything good available, and this section will attempt to fill that gap.
 For now, read the [http://codespeak.net/z3/five/manual.html Five Manual], grab the Five source code, and work through the <tt>demos</tt> directory.

@@ Line 40: / Line 40: @@
 ;Local Components: Local components are components that are not instantiated as part of the Global Component Registry. They are typically stored in the traditional Zope storage infrastructure, the ZODB, which also means that they are ''persistent'', in that they will survive multiple application starts/stops. Because they exist in the ZODB, Zope will use ''acquisition'' (a traditional Zope way of finding things in the ZODB) to retrieve local components when your application queries the ZODB.
 ;ZCML: Pronounced "Z-camel", ZCML is an XML-based configuration file syntax that is used to register components with the global component registry. It is useful in that it provides a mechanism to add new components using configuration files rather than touching source code. It also provides a mechanism to easily extend ZCA code by overriding existing components with new implementations -- all without touching existing Python source code.
-;Adapters: Adapters are Python classes that add new Interfaces to existing objects, so they can be used in new ways. More specifically, an Adapter class will contain an <tt>adapts()</tt> call in the class body that specifies that it ''adapts'' an interface, which means that you can pass any object that implements that interface to the adapter class' <tt>__init__()</tt> method, such as <tt>a = myAdapter(myobject)</tt>. <tt>MyAdapter</tt> now takes care of acting as a front-end for <tt>myobject</tt> so that any interfaces implemented by <tt>myAdapter</tt> will interact properly with <tt>myobject</tt>.
+;Adapters: Adapters are Python classes that allow new interfaces to be used with existing objects. More specifically, an Adapter class will contain an <tt>adapts()</tt> call in the class body that specifies that it ''adapts'' an interface, which means that you can pass any object that implements that interface to the adapter class' <tt>__init__()</tt> method, such as <tt>a = myAdapter(myobject)</tt>. <tt>MyAdapter</tt> now takes care of acting as a front-end for <tt>myobject</tt> so that any interfaces implemented by <tt>myAdapter</tt> will interact properly with <tt>myobject</tt>. In a sense, the adapter "eats" the adapted object.
 ;Factories: A factory is something (technically, a ''Utility'', see below) that creates components and objects. It is like a higher-level version of a constructor. A Factory must be ''callable'' and implement the <tt>IFactory</tt> interface. Factories offer a convenient means to access component constructors via a component registry, rather than connecting to the constructor directly in Python code. It's important to note that ''ZCML creates factories for you automatically when you register components. This means that in many cases, you do not need to deal directly with Factory creation.''
 ;Utilities: A utility is a Python object that you want to add to the component registry. It could be any type of Python object that another part of your application may need. A utility must implement at least one interface. [http://bluebream.zope.org/doc/1.0/howto/localsitemanager.html#how-does-it-usually-look-like The Zope Documentation] has some guidance on when it's appropriate to create a utility.

@@ Line 36: / Line 36: @@
 ;Interfaces: Interfaces are special Python classes that are declared for the sole purpose of describing functionality implemented by another class or module. They are registered with a component registry, and others can query the registry for components that implement a particular interface. Objects can advertise that they implement a particular interface. From a code perspective, interfaces are the heart of ZCA.
 ; Services: A service is generally a Python object that deals with components, and provides some functionality to your application. Think of components as "things", and services as parts of your code that take these "things" and perform useful actions with them.
-;Component Registry: The Component Registry, also called a ''Site Manager'', is a directory of components, and acts as the central organizational hub of ZCA. It is a ''service'' (as defined above.) You register components with the component registry, and then others can query the registry for components that they need. There is a ''global'' component registry and a ''local'' component registry.
+;Component Registry: The Component Registry, also called a ''Site Manager'', is a directory of components, and acts as the central organizational hub of ZCA. It is a ''service'' (as defined above.) You register components with the component registry, and then others can query the registry for components that they need. There is a ''global'' component registry that is automatically created for you, and you can use the ZODB as a ''local'' component registry.
 ;Global Component Registry: The Global Component Registry a service that is automatically created when your ZCA-based application starts, and is populated with components based on your application's ZCML configuration files. Any part of your application can access the Global Component Registry. When your application shuts down, the Global Component Registry no longer exists. It will be re-initialized from ZCML when your application is started again.
 ;Local Components: Local components are components that are not instantiated as part of the Global Component Registry. They are typically stored in the traditional Zope storage infrastructure, the ZODB, which also means that they are ''persistent'', in that they will survive multiple application starts/stops. Because they exist in the ZODB, Zope will use ''acquisition'' (a traditional Zope way of finding things in the ZODB) to retrieve local components when your application queries the ZODB.