NewsletterGlossary

This glossary is simply a collection of the items in each Zope 3 Newsletter glossary. As such, it is yet another glossary for Zope 3: see also Glossary.

Adapter Service: a tool that, given one "component" (an object that declares an interface) and a desired resulting interface, tries to wrap the component with extra functionality that matches the desired interface (forgive the simplification!)
Event Service: An internal system (not intended to be external) that can send events to interested object subscribers.
Forms: Allows you to create (web) forms in a structured, secure and easy way. First create the schema. This is just an interface with schema information on it. From the schema, a form can be generated automatically using widgets from an extensible set. User input to the form is then automatically converted to the value types the schema expects, and can then be validated against the schema to check whether the values fit the schema criteria. If any errors occur they can be displayed to the end user (possibly along with the form itself). (thanks to Martijn Faassen)
Global: see placeless
Global Service: see placeless service.
I18N: In Zope 3, i18n covers all that is needed to have an application be able to be switched from one language to another, or being able to support multiple languages at the same time, be it for its interface or for its content objects themselves. That covers input and output encoding, translatability and actual translation of views and contents, the tools and formats necessary to provide those translations, maybe even the translation workflows that authors will use. (thanks to Florent Guillaume for the corrected definition)
Interface: a description of the behavior of objects. Zope provides objects for representing interfaces and a facility for asserting that objects implement interfaces. Interface objects were added to Zope for specification and documentation purposes. Zope 3 uses interfaces primarily for classification and for connecting components based on compatible interfaces. Future versions of Zope may utilize interfaces for type safety, as part of the security system.
Local: see placeful
Local Service: see placeful service.
Object Hub: A way to assign an object's path in the ZODB to an integer unique to that hub instance. Thanks to the Event Service, the Object Hub can maintain the integer-to-object-path relationship even if the object moves. See ObjectHub for a longer definition in the official glossary.
Persistent: the base class that makes it possible for an object to be stored (mostly) transparently in the ZODB
Placeful: An adjective describing an object that has a traversal context in Zope. For example, an object is placeful if it can be reached by traversing a URI path, be it "/myObject", "/myFolder/myObject", "/myFolder/myNonZODBConnection/myObject", or "/++etc++Services/Packages/default/myErrorService" (the last example is a hypothetical placeful service). More technically, these objects are wrapped, mostly invisibly, with one or more "Zope.ContextWrapper?"s, which provide the ability to get contextual information similar to aq_parent etc. in Zope 2; moreover, following these nested wrappers to their ultimate (top or root) context must reach the top (root) Zope object (i.e., the object found by traversing the path "/"). Note that the correct usage of context wrappers should actually use the methods in Zope.Proxy.ContextWrapper?, which also provide and handle security proxies. Opposite of placeless.
Placeful Service: a service that is placeful and is pertinent only to the Zope traversal branch (or "folder" and all children) in which it resides. This usually means that the service resides in the ZODB (and so is persistent). Similar to standard programming "local" concept of variables in that a placeful service's scope is restricted, where the scope in this case is the scope of a traversal branch. A placeful service is usually obtained by using a traversal context to get it: in Python, after importing Zope.ComponentArchitecture.getService, one would use getService(myTraversalContext, "Events") to get a placeful event service, where myTraversalContext is another placeful object. Note that if a placeful event service is not installed within the traversal context, a placeless service, if such exists with the requested name (such as "Events"), will be returned. Opposite of placeless service.
Placeless: An adjective describing an object that does not have a traversal context, and usually is not intended to have one. This usually means that one cannot traverse to such an object via any URL path, for instance. Technically, it also means that these objects do not have nested "Zope.ContextWrapper?"s that resolve eventually and finally to the root Zope object (i.e., URI path "/") and, in fact, in all to almost all cases, means that they do not have any ContextWrappers? at all. Opposite of placeful.
Placeless Service: a service that is placeless and is available to any object. This usually means that it does not reside in the ZODB and is not persistent--connections to placeless services, therefore, usually must be made on every Zope startup, and are often controlled through ZCML. Somewhat similar to standard programming "global" concept of variables, in that they are not restricted by any scope, where scope in this case is the scope of traversal context (that is, the context of where an object is found in Zope via URI path). A placeless service can be obtained (if one by the requested name is installed) in Python by importing Zope.ComponentArchitecture.getService and then calling "getService(None, Events)"--that is, the traversal context (first argument) is None. Opposite of Placeful.
Relationship Service: A proposed central place to store relationships between objects, giving some very simple and basic relational-database-like functionality. A client of the ObjectHub.
Schema: A Zope 3 framework built on the Interface package that allows you to specify details about attributes of the object that implements the schema. This includes type information (string, integer, etc) as well as restrictions on what values may be set (maximum length, can be None, etc) which can be automatically validated. The schema framework allows you to specify this information in an object's interface. Schema information is used by several other Zope 3 systems, such as metadata (properties) and forms. The schema package lives in lib/python/Zope/Schema. (thanks to Martijn Faassen)
Service: (TBD. I guess I will use some friendly massaged version of http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Service ...)
Sprint: A sprint is a multi-day session of intense Zope 3 development organized around extreme programming (XP) ideas such as pair programming. (stolen from SprintSchedule which tells a lot more!)
Traversal Context: (TBD again: help?. After some relatively short definition we come up with then I probably will put Steve's traversal analogy up in a link.)
TTW: "Through the web," usually used in reference to ideas such as "scripting TTW" or "configuring TTW" and so on.
Utility: (TBD massaging of other glossary entries...)
ZCML: Zope Configuration Meta Language. The XML language that is the file-system configuration tool for site administrators. One uses it to declare new Zope 3 products, new services, new views, and so on.
ZODB: Zope Object Database. A way to store Python objects persistently; an underlying technology of Zope 2 and 3, but also available in a stand-alone distribution.