Acquisition
Acquisition is the technology that allows dynamic behavior to be shared between Zope objects via containment.
Anonymous User - June 25, 2005 5:28 pm: piosdfoimk,
Acquisition's flavor permeates Zope. It can be used almost everywhere within Zope: in DTML, in Zope Page Templates, in Script (Python) objects, and even in Zope URLs. Because of its ubiquity in Zope, a basic understanding of acquisition is important.
Anonymous User - June 25, 2005 5:29 pm: also
Acquisition vs. Inheritance
The chapter entitled Object Orientation describes a concept called inheritance. Using inheritance, an object can inherit some of the behaviors of a specific class, overriding or adding other behaviors as necessary. Behaviors of a class are nearly always defined by its methods, although attributes can be inherited as well.
In a typical object-oriented language, there are rules to the way
a subclass inherits behavior from its superclasses. For
example, in Python (a multiple-inheritance language), a class
may have more than one superclass, and rules are used to determine
which of a class' superclasses is used to define behavior in any
given circumstance. We'll define a few Python classes here to
demonstrate. You don't really need to know Python inside and out
to understand these examples. Just know that a class
statement
defines a class and a def
statement inside of a class statement
defines a method. A class statement followed by one or more words
inside (Parenthesis) causes that class to inherit behavior from
the classes named in the parenthesis.:
class SuperA: def amethod(self): print "I am the 'amethod' method of the SuperA class" def anothermethod(self): print "I am the 'anothermethod' method of the SuperA class" class SuperB: def amethod(self): print "I am the 'amethod' method of the SuperB class" def anothermethod(self): print "I am the 'anothermethod' method of the SuperB class" def athirdmethod(self): print "I am the 'anothermethod' method of the SuperB class" class Sub(SuperA, SuperB): def amethod(self): print "I am the 'amethod' method of the Sub class"
Anonymous User - Jan. 12, 2004 11:08 pm: In the SuperB class, athirdmethod() should probably print that it is the 'athirdmethod' method, rather than the 'anothermethod' method (which it isn't). It might confuse people who are new or (like me) sleepy.
Anonymous User - Sep. 22, 2004 7:06 pm: "class'" should be "class's". The word is singular, so it still takes a possessive "'s", even though it already ends in "s".
Anonymous User - Oct. 9, 2004 5:25 pm: Not the way I learned it. The plural of class is classes. The possessive is class'. Examples: - seventeen classes - the class' methods
Anonymous User - Sep. 27, 2005 10:00 am: > The word is singular, so it still takes a possessive "'s", even though it already ends in "s". No, that's only for proper names: - The top brass' aides were present. - Jones's lawnmower broke.
If we make an instance of the "Sub" class, and attempt to call one of its methods, there are rules in place to determine whether the behavior of the method will be defined by the Sub class itself, its SuperA superclass, or its SuperB superclass. The rules are fairly simple. If the Sub class has itself defined the named method, that method definition will be used. Otherwise, the inheritance hierarchy will be searched for a method definition.
The inheritance hierarchy is defined by the class' superclass definitions. In the case of the Sub class above, it has a simple inheritance hierarchy: it inherits first from the SuperA superclass, then it inherits from the SuperB superclass. This means that if you call a method on an instance of the Sub class, and that method is not defined as part of the Sub class' definition, it will first search for the method in the SuperA class and if it doesn't find it there, it will search in the SuperB class.
Anonymous User - Jan. 30, 2004 11:26 pm: This is probably nitpicking, but you should probably explain that the order in which the superclasses are named in the subclass definition is what is important, not the fact that 'A' comes before 'B' in the alphabet (which an unsuspecting reader might assume).
Anonymous User - June 10, 2005 4:04 am: The statement is confusing in that it first says 'it inherits first from the SuperA superclass, then it inherits from the SuperB superclass'. This SHOULD mean that any method present in SuperB with the same name as a method present in SuperA will shadow the SuperA one (just as it is in C++). However it goes on to say that the interpreter will stop at the first occurrence of the method. This impossibilitates overriding. Is the paragraph wrong or does Python really work this way?
Here is an example of calling methods on an instance of the above-defined Sub class using the Python interpreter:
>>> instance = Sub() >>> instance.amethod() I am the 'amethod' method of the Sub class >>> instance.anothermethod() I am the 'anothermethod' method of the SuperA class >>> instance.athirdmethod() I am the 'anothermethod' method of the SuperB class
Anonymous User - Jan. 12, 2004 11:09 pm: If the athirdmethod() in SuperB is adjusted per the suggestion that it output that it is 'athirdmethod' instead of 'anothermethod', this output should probably be updated to reflect that as well.
Note that when we called the anothermethod
method on the Sub
instance, we got the return value of SuperA's method definition
for that method, even though both SuperA and SuperB defined that
method. This is because the inheritance hierarchy specifies that
the first superclass (SuperA) is searched first.
The point of this example is that instances of objects use their inheritance hierarchy to determine their behavior. In non-Zope applications, this is the only way that object instances know about their set of behaviors. However, in Zope, objects make use of another facility to search for their behaviors: acquisition.
Acquisition is about Containment
The concept behind acquisition is simple:
- Objects are situated inside other objects. These objects act as their "containers". For example, the container of a DTML Method named "amethod" inside the DTML_Example folder is the DTML_Example folder.
- Objects may acquire behavior from their containers.
Inheritance stipulates that an object can learn about its behavior from its superclasses via an inheritance hierarchy. Acquisition, on the other hand, stipulates that an object can additionally learn about its behavior through its containment hierarchy. In Zope, an object's inheritance hierarchy is always searched for behavior before its acquisition hierarchy. If the method or attribute is not found in the object's inheritance hierarchy, the acquisition hierarchy is searched.
Say What?
Let's toss aside the formal explanations. Acquisition can be best explained with a simple example.
Place a DTML Method named acquisition_test
in your Zope root
folder. Give it the following body:
<html> <body> <p> I am being called from within the <dtml-var title> Folder! </p> </body> </html>
Save it and then use the DTML Method "View" tab to see the result of the DTML method in your Workspace frame. You will see something not unlike the following:
I am being called from within the Zope Folder!
The title
of the Zope root folder is Zope
, so this makes
sense. Now create a Folder inside your Zope root folder
named AcquisitionTestFolder
and a title of
"TheAcquisitionTest". We're going to invoke the
acquisition_test
method in the context of the
AcquisitionTestFolder folder. To do this, assuming your
Zope is running on your local machine on port 8080, visit
the URL
http://localhost:8080/AcquisitionTestFolder/acquisition_test
.
You will see something not unlike the following:
I am being called from within the TheAcquisitionTest Folder!
Note that even though an object named acquisition_test
does not
"live" inside the AcquisitionTestFolder folder, Zope found the
method and displayed a result anyway! Not only did Zope display a
result, instead of inserting the title
of the Zope root folder, it
inserted the title
of the AcquisitionTestFolder folder! This is an
example of acquisition in action. The concept is simple: if a
named object is not found as an attribute of the object you're
searching, its containers are searched until the object is found.
In this way, acquisition can add behavior to objects. In this
case, we added a behavior to the AcqusitionTestFolder folder that
it didn't have before (by way of giving it an acquisition_test
method).
Providing Services
It can be said that acquisition allows objects to acquire
services by way of containment. For example, our
AcquisitionTestFolder folder acquired the services of the
acquisition_test
method.
Not only do objects acquire services, they also provide them. For
example, adding a Mail Host object to a Folder named AFolder
provides other objects in that folder with the ability to send
mail. But it also provides objects contained in subfolders of
that folder with the capability to send mail. If you create
subfolders of AFolder
named AnotherFolder
and AThirdFolder
,
you can be assured that objects placed in these folders will
also be able to send mail in exactly the same way as objects
placed in AFolder
.
Acquisition "goes both ways". When you create an object in Zope, it has the capability to automatically acquire services. Additionally, it automatically provides services that other objects can acquire. This makes reuse of services very easy since you don't have to do anything special to make services available to other objects.
Getting Deeper with Multiple Levels
If you place a method in the root folder, and create a subfolder in the root folder, you can acquires the method's behaviors. So what happens if things get more complex? Perhaps you have a method that needs to be acquired from withinside a couple of folders. Is it acquired from its parent, or its parent's parent, or what?
Chirael - Mar. 25, 2004 4:23 am: I believe there are two errors here: "you can aquires the method's behaviors" (should be acquire) and "acquired from withinside" (should be within).
Anonymous User - Oct. 21, 2005 3:35 am: Correct, those are two typos and/or spelling mistakes.
The answer is that acquisition works on the entire object hierarchy. If for example you have a DTML Method in the root folder. Also in the root folder you have three nested Folders named "Users", "Barney" and "Songs". You may call this URL:
/Users/Barney/Songs/HappySong
Chirael - Mar. 25, 2004 4:24 am: Might be helpful to say "you have a DTML Method in the root folder called HappySong", just so that smart readers can figure it out right when looking at the URL, instead of having to go on to the next paragraph to find out what the method is called and thus have the URL make sense.
The HappySong method is found in the root folder unless one of the other folders "Users", "Barney" or "Songs" happens to also have a method named "HappySong", in which case that method is used. The HappySong method is searched for first directly in the "Songs" folder. If it is not found, the acquisition hierarchy is searched starting at the first container in the hierarchy: "Barney". If it is not found in "Barney", the "Users" folder is searched. If it is not found in the "Users" folder, the root folder is searched. This search is called searching the acquisition path or alternately searching the containment hierarchy.
Anonymous User - June 8, 2004 12:03 am: If "happySong" method is no found in the root folder, is the "AnotherUser" folder searched?
Aquisition is not limited to searching a containment hierarchy: it can also search a context hierarchy. Acquisition by context is terribly difficult to explain, and you should avoid it if possible. However, if you want more information about aquiring via a context and you are ready to have your brain explode, please see the presentation named Acquisition Algebra.
Anonymous User - Mar. 31, 2004 2:22 pm: The description of class inheritance earlier was useful, but this should tie it into the concept of aquisition a bit more. It would appear (I think?) that a class is created for each unique object at each level of the containment hierarchy and that aquisition is really just glorified subclassing. Some additional explanation of how these directly correspond might be helpful. For instance, the earlier text makes a point of describing python's multiple inheritance rules; how are those relevant for aquisition?
Anonymous User - Apr. 23, 2004 11:20 am: I don't know anything about Zope, and this point is as far as I have gotten in the manual so far. To me it would seem that some of the classes would be "Folder", "DTML Method", etc. Each unique object would then be an instance. So acquisition for a folder means that each folder instance appears to contain the object instances that its parent's instances contain. So, while it has a similar effect to subclassing, it works on instances instead of classes, and except for "Context Acquisition" it seems to always behave like single inheritance.
Anonymous User - Nov. 16, 2004 1:03 am: Just a test
Summary
Acquisition allows behavior to be distributed throughout the system. When you add a new object to Zope, you don't need to specify all its behavior, only the part of its behavior that is unique to it. For the rest of its behavior it relies on other objects. This means that you can change an object's behavior by changing where it is located in the object hierarchy. This is a very powerful function which gives your Zope applications flexibility.
Acquisition is useful for providing objects with behavior that doesn't need to be specified by their own methods or methods found in their inheritance hierarchies. Acquisition is particularly useful for sharing information (such as headers and footers) between objects in different folders as well. You will see how you can make use of acquisition within different Zope technologies in upcoming chapters.
A more exhaustive technical explanation of the underpinnings of Zope's acquisition technology is available in the Zope Developer's Guide.