Modified items

All recently modified items, latest first.

zope.datetime-3.4.1-2.lbn19.noarch: Commonly used date and time related utility functions.

zope.copypastemove-4.0.0-1.lbn19.noarch: This package provides Copy, Paste and Move support for content components in Zope. In particular, it defines the following interfaces for this kind of functionality: * IObjectMover, * IObjectCopier, * IContentItemRenamer, * IPrincipalClipboard as well as standard implementations for containers and contained objects as known from the zope.container package.

zope.copy-4.0.0-2.lbn19.noarch: 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.

zope.contenttype-4.2.0-1.lbn19.noarch: A utility module for content-type handling.

zope.contentprovider-4.0.0-1.lbn19.noarch: This package provides a framework to develop componentized Web GUI applications. Instead of describing the content of a page using a single template or static system of templates and METAL macros, content provider objects are dynamically looked up based on the setup/configuration of the application.

zope.container-4.1.0-1.lbn19.x86_64: This package define interfaces of container components, and provides container implementations such as a BTreeContainer and OrderedContainer, as well as the base class used by zope.site.folder for the Folder implementation.

zope.container-3.12.0-2.lbn19.armv6hl: This package define interfaces of container components, and provides container implementations such as a BTreeContainer and OrderedContainer, as well as the base class used by zope.site.folder for the Folder implementation.

zope.configuration-4.0.3-1.lbn19.noarch: 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.

zope.componentvocabulary-2.0.0-1.lbn19.noarch: This package contains various vocabularies.

zope.component-4.3.0-1.lbn19.noarch: Zope Component API

zope.catalog-3.8.2-2.lbn19.noarch: Catalogs provide management of collections of related indexes with a basic search algorithm.

zope.cachedescriptors-4.2.0-1.lbn19.noarch: Cached descriptors cache their output. They take into account instance attributes that they depend on, so when the instance attributes change, the descriptors will change the values they return. Cached descriptors cache their data in _v_ attributes, so they are also useful for managing the computation of volatile attributes for persistent objects. Persistent descriptors: property A simple computed property. See property.txt. method Idempotent method. The return values are cached based on method arguments and on any instance attributes that the methods are defined to depend on. **Note**, only a cache based on arguments has been implemented so far. See method.txt. Cached Properties ----------------- Cached properties are computed properties that cache their computed values. They take into account instance attributes that they depend on, so when the instance attributes change, the properties will change the values they return.

zope.browserresource-4.1.0-1.lbn19.noarch: This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the Zope Toolkit project. This package provides an implementation of browser resources. It also provides directives for defining those resources using ZCML. Resources are static files and directories that are served to the browser directly from the filesystem. The most common example are images, CSS style sheets, or JavaScript files. Resources are be registered under a symbolic name and can later be referred to by that name, so their usage is independent from their physical location. You can register a single file with the <browser:resource> directive, and a whole directory with the <browser:resourceDirectory> directive, for example <browser:resource file=”/path/to/static.file” name=”myfile” /> <browser:resourceDirectory directory=”/path/to/images” name=”main-images” /> This causes a named adapter to be registered that adapts the request to zope.interface.Interface (XXX why do we not use an explicit interface?), so to later retrieve a resource, use zope.component.getAdapter(request, name=’myfile’). There are two ways to traverse to a resource, with the ‘empty’ view on a site, e. g. http://localhost/@@/myfile (This is declared by zope.browserresource) with the ++resource++ namespace, e. g. http://localhost/++resource++myfile (This is declared by zope.traversing.namespace) In case of resource-directories traversal simply continues through its contents, e. g. http://localhost/@@/main-images/subdir/sample.jpg Rather than putting together the URL to a resource manually, you should use zope.traversing.browser.interfaces.IAbsoluteURL to get the URL, or for a shorthand, call the resource object. This has an additional benefit: If you want to serve resources from a different URL, for example because you want to use a web server specialized in serving static files instead of the appserver, you can register an IAbsoluteURL adapter for the site under the name ‘resource’ that will be used to compute the base URLs for resources. For example, if you register ‘http://static.example.com/’ as the base ‘resource’ URL, the resources from the above example would yield the following absolute URLs: http://static.example.com/@@/myfile and http://static.example.com/@@/main-images

zope.browserpage-4.1.0-2.lbn19.noarch: This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the Zope Toolkit project. This package provides ZCML directives for configuring browser views. More specifically it defines the following ZCML directives: browser:page browser:pages browser:view These directives also support menu item registration for pages, when zope.browsermenu package is installed. Otherwise, they simply ignore the menu attribute.

zope.browsermenu-4.1.1-2.lbn19.noarch: This package provides shared browser components for the Zope Toolkit.

zope.browser-2.1.0-1.lbn19.noarch: This package provides shared browser components for the Zope Toolkit.

zope.broken-3.6.0-2.lbn19.noarch: This package defines a marker interface, zope.broken.IBroken, used to identify objects which cannot be correctly loaded from the ZODB, typically because the class named in their pickle is not importable. The package exists as a dependency inversion, preventing packages which need to use this interface (e.g., zope.container) from inheriting the dependencies of zope.app.broken (where the interface used to be defined).

zope.bforest-1.2-2.lbn19.noarch: BForests are dictionary-like objects that use multiple BTrees for a backend and support rotation of the composite trees. This supports various implementations of timed member expirations, enabling caches and semi-persistent storage. A useful and simple subclass would be to promote a key-value pair to the first (newest) bucket whenever the key is accessed, for instance. It also is useful with disabling the rotation capability. Like btrees, bforests come in four flavors: Integer-Integer (IIBForest), Integer-Object (IOBForest), Object-Integer (OIBForest), and Object-Object (OOBForest). The examples here will deal with them in the abstract: we will create classes from the imaginary and representative BForest class, and generate keys from KeyGenerator and values from ValueGenerator. From the examples you should be able to extrapolate usage of all four types.

zope.authentication-3.7.1-2.lbn19.noarch: Definition of authentication basics for the Zope Framework

zope.applicationcontrol-3.5.5-2.lbn19.noarch: Zope applicationcontrol

« Previous 20 items Next 20 items » 1 2 3 4 5 6 7 8 ... 2252

Sections

Personal tools

Modified items