Share this Page URL
Help

Chapter 7. The Component Architecture: A... > Global Versus Local Components - Pg. 36

The Component Architecture: An Introduction 36 Global Versus Local Components Zope 3 consciously separates local and global components. Global components have no place associated with them and are therefore always reachable and present. They are always initialized and registered at Zope 3 startup via ZCML, as mentioned previously. Therefore, global components are not persistent, which means they are not stored in the Zope Object Database (ZODB) at all. Their state is destroyed (and should be) upon server shutdown. Local components, on the other hand, are stored in the ZODB at the place in the object tree where they were defined. Local components always only add and overwrite previous settings; they can never remove existing ones. You can create new local components through the Web interface by clicking Manage Site. This leads you into the configuration namespace, which is always marked by ++etc++site in the URL. Every folder can be promoted to become a site. When you declare a local site manager for a folder by clicking Make Site, you call this object/folder a site . As mentioned earlier in this chapter, local components use an explicit acquisition process when looking up information. For example, you may want to get the factory for SimpleExample. When looking for any component, the original site of the publication is chosen. However, sometimes you want to start looking for a component from a different site. In such a case, you simply specify the context in the call, as in this example: 01 from zope.component.interfaces import IFactory 02 factory = zapi.getUtility(IFactory, 'example.SimpleExample', context=other_site) If a local utility service exists and an IFactory utility with the name example.SimpleExample is found, then the factory is returned. Otherwise, the local utility service delegates the request to the next site. Requests can be delegated all the way up to the global utility service, at which point an answer must be given. If the global Utility Service does not know the answer either, a Componen- tLookupError error is raised. You can see that there are slight semantic differences between global and local implementations of a service, besides the differences in data storage and accessibility. The global service never has to worry about place or the delegation of the request. The net effect is that global components are often easier to implement than their local equivalents. Furthermore, local components usually have writable APIs in addition to the readable ones because they have to allow runtime management.