Modified items

All recently modified items, latest first.

zope.i18nmessageid-3.5.3-1.lbn13.x86_64: To translate any text, we must be able to discover the source domain of the text. A source domain is an identifier that identifies a project that produces program source strings. Source strings occur as literals in python programs, text in templates, and some text in XML data. The project implies a source language and an application context. We can think of a source domain as a collection of messages and associated translation strings. We often need to create unicode strings that will be displayed by separate views. The view cannot translate the string without knowing its source domain. A string or unicode literal carries no domain information, therefore we use messages. Messages are unicode strings which carry a translation source domain and possibly a default translation. They are created by a message factory. The message factory is created by calling MessageFactory with the source domain. This package provides facilities for delaring such messages within program source text; translation of the messages is the responsiblitiy of the 'zope.i18n' package.

zope.i18n-3.8.0-2.lbn13.noarch: This package implements several APIs related to internationalization and localization. * Locale objects for all locales maintained by the ICU project. * Gettext-based message catalogs for message strings. * Locale discovery for Web-based requests.

zope.html-2.1.0-2.lbn13.noarch: HTML and XHTML Editing Support

zope.hookable-4.0.0-2.lbn13.x86_64: 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.

zope.globalrequest-1.0-2.lbn13.noarch: Global way of retrieving the currently active request.

zope.formlib-4.0.6-2.lbn13.noarch: Forms are web components that use widgets to display and input data. Typically a template displays the widgets by accessing an attribute or method on an underlying class. For further information, please refer to form.txt, namedtemplate.txt and errors.txt inside the zope.formlib package.

zope.filerepresentation-3.6.1-2.lbn13.noarch: The interfaces defined here are used for file-system and file-system-like representations of objects, such as file-system synchronization, FTP, PUT, and WebDAV.

zope.file-0.6.2-1.lbn13.noarch: Efficient File Implementation for Zope Applications

zope.exceptions-3.6.2-2.lbn13.noarch: This package contains exception interfaces and implementations which are so general purpose that they don't belong in Zope application-specific packages.

zope.event-3.5.2-1.lbn13.noarch: The ``zope.event`` package provides a simple event system. It provides: - An event publishing system - A very simple event-dispatching system on which more sophisticated event dispatching systems can be built. For example, a type-based event dispatching system that builds on ``zope.event`` can be found in ``zope.component``

zope.error-3.7.4-2.lbn13.noarch: This package provides an error reporting utility which is able to store errors.

zope.dublincore-3.8.2-2.lbn13.noarch: zope.dublincore provides a Dublin Core support for Zope-based web applications. This includes: * an IZopeDublinCore interface definition that can be implemented by objects directly or via an adapter to support DublinCore metadata. * an IZopeDublinCore adapter for annotatable objects (objects providing IAnnotatable from zope.annotation). * a partial adapter for objects that already implement some of the IZopeDublinCore API, * a "Metadata" browser page (which by default appears in the ZMI), * subscribers to various object lifecycle events that automatically set the created and modified date and some other metadata.

zope.dottedname-3.4.6-2.lbn13.noarch: The zope.dottedname module provides one function, resolve that resolves strings containing dotted names into the appropriate python object. Dotted names are resolved by importing modules and by getting attributes from imported modules. Names may be relative, provided the module they are relative to is supplied.

zope.documenttemplate-3.4.3-2.lbn13.noarch: zope.documenttemplate

zope.deprecation-3.4.1-3.lbn13.noarch: When we started working on Zope 3.1, we noticed that the hardest part of the development process was to ensure backward-compatibility and correctly mark deprecated modules, classes, functions, methods and properties. This package provides a simple function called 'deprecated(names, reason)' to deprecate the previously mentioned Python objects.

zope.deferredimport-3.5.3-3.lbn13.noarch: 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.

zope.decorator-3.4.0-4.lbn13.noarch: zope.decorator

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

zope.copypastemove-3.8.0-2.lbn13.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.lbn13.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.

« Previous 20 items Next 20 items » 1 ... 2362 2363 2364 2365 2366 2367 2368 ... 2448


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items