Personal tools
Skip to content. | Skip to navigation
This suite forms the pure Python base classes for projects and project-related classes within the PMOBoss suite. Everything known (and knowable) about a pmoproject is contained within the base classes in this module. The parsers directory contains parser classes which are responsible for taking file types and translating these into the base classes. The reason that this library is pure Python is because we want to be able to reliably test all the attributes of this base and to test that parser's indeed rend these properly. The test directory contains the regression/unit testing suite for these classes, and the codegen directory contains some useful scripts to autogenerate python code stubs for other Zope and Plonish applications.
MSProject XML parser which converts an entire project into pythonesque structures. The parser recognises 2003, 2007, and 2010 MSProject formats.
MSProject XML parser which just chunks the uninteresting stuff
Zope component architecture
The zope configuration system provides an extensible system for supporting various kinds of configurations. It is based on the idea of configuration directives. Users of the configuration system provide configuration directives in some language that express configuration choices. The intent is that the language be pluggable. An XML language is provided by default.
This package provides a pluggable way to copy persistent objects. It was once extracted from the zc.copy package to contain much less dependencies. In fact, we only depend on zope.interface to provide pluggability. The package provides a clone function that does the object cloning and the copy wrapper that sets __parent__ and __name__ attributes of object's copy to None. This is useful, when working with Zope's located objects (see zope.location package). The copy function actually calls the clone function so we'll use the first one in the examples below. We'll also look a bit at their differences in the end of this document. The clone function (and thus the copy function that wraps it) uses pickling to copy the object and all its subobjects recursively. As each object and subobject is pickled, the function tries to adapt it to zope.copy.interfaces.ICopyHook. If a copy hook is found, the recursive copy is halted. The hook is called with two values: the main, top-level object that is being copied; and a callable that supports registering functions to be called after the copy is made. The copy hook should return the exact object or subobject that should be used at this point in the copy, or raise zope.copy.interfaces.ResumeCopy exception to resume copying the object or subobject recursively after all. Note that we use zope's component architecture provided by the zope.component package in this document, but the zope.copy package itself doesn't use or depend on it, so you can provide another adaptation mechanism as described in zope.interface's adapter documentation.
Often, especially for package modules, you want to import names for convenience, but not actually perform the imports until necessary. The zope.deferredimport package provided facilities for defining names in modules that will be imported from somewhere else when used. You can also cause deprecation warnings to be issued when a variable is used.
Hookable object support. Support the efficient creation of hookable objects, which are callable objects that are meant to be replaced by other callables, at least optionally. The idea is you create a function that does some default thing and make it hookable. Later, someone can modify what it does by calling its sethook method and changing its implementation. All users of the function, including those that imported it, will see the change.
================= Life-cycle events ================= In Zope 3, events are used by components to inform each other about relevant new objects and object modifications. To keep all subscribers up to date it is indispensable that the life cycle of an object is accompanied by various events. >>> from zope.event import notify >>> from zope.lifecycleevent import ObjectCreatedEvent, ObjectModifiedEvent >>> class Sample(object) : ... "Test class" >>> obj = Sample() >>> notify(ObjectCreatedEvent(obj)) >>> obj.modified = True >>> notify(ObjectModifiedEvent(obj)) Zope 3's Dublin Core Metadata for instance, rely on the bare ObjectCreatedEvent and ObjectModifiedEvent to record creation and modification times. Other event consumers like catalogs and caches may need more information to update themselves in an efficient manner. The necessary information can be provided as optional modification descriptions of the ObjectModifiedEvent. Some examples: >>> from zope.interface import Interface, Attribute, implements >>> class IFile(Interface): ... data = Attribute("Data") ... >>> class File(object): ... implements(IFile) ... >>> file = File() >>> file.data = "123" >>> notify(ObjectModifiedEvent(obj, IFile)) This says that we modified something via IFile. Note that an interface is an acceptable description. In fact, we might allow pretty much anything as a description and it depends on your needs what kind of descriptions you use. In the following we use an IAttributes description to describe in more detail which parts of an object where modified : >>> file.data = "456" >>> from zope.dublincore.interfaces import IZopeDublinCore >>> from zope.interface import directlyProvides >>> from zope.annotation.interfaces import IAttributeAnnotatable >>> directlyProvides(file, IAttributeAnnotatable) >>> IZopeDublinCore(file).title = u"New title" >>> IZopeDublinCore(file).title = u"New description" >>> from zope.lifecycleevent import Attributes >>> event = ObjectModifiedEvent( ... obj, ... Attributes(IFile, 'data'), ... Attributes(IZopeDublinCore, 'title', 'description'), ... ) >>> notify(event) This says we modified the file data and the DC title and description.