Modified items

All recently modified items, latest first.

zope.mkzeoinstance-4.1-1.lbn25.noarch: This package provides a single script, mkzeoinstance, which creates a standalone ZEO server instance.

zope.minmax-2.1.0-1.lbn25.noarch: This package provides support for homogeneous values favoring maximum or minimum for ZODB conflict resolution. See src/zope/minmax/minmax.txt for a detailed description.

zope.mimetype-2.1.0-1.lbn25.noarch: This package provides a way to work with MIME content types. There are several interfaces defined here, many of which are used primarily to look things up based on different bits of information. The Zope MIME Infrastructure This package provides a way to work with MIME content types. There are several interfaces defined here, many of which are used primarily to look things up based on different bits of information. The basic idea behind this is that content objects should provide an interface based on the actual content type they implement. For example, objects that represent text/xml or application/xml documents should be marked mark with the IContentTypeXml interface. This can allow additional views to be registered based on the content type, or subscribers may be registered to perform other actions based on the content type. One aspect of the content type that’s important for all documents is that the content type interface determines whether the object data is interpreted as an encoded text document. Encoded text documents, in particular, can be decoded to obtain a single Unicode string. The content type intefaces for encoded text must derive from IContentTypeEncoded. (All content type interfaces derive from IContentType and directly provide IContentTypeInterface.) The default configuration provides direct support for a variety of common document types found in office environments.

zope.login-2.0.0-2.lbn25.noarch: This package provides a login helpers for zope.publisher based on the concepts of zope.authentication.

zope.location-4.2-1.lbn25.noarch: In Zope3, location are special objects that has a structural location.

zope.lifecycleevent-4.1.0-1.lbn25.noarch: ================= 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. ======= CHANGES ======= 3.5.2 (2009-05-17) ------------------ - ``IObjectMovedEvent``, ``IObjectAddedEvent``, ``IObjectRemovedEvent`` interfaces and ``ObjectMovedEvent``, ``ObjectAddedEvent`` and ``ObjectRemovedEvent`` classes copied here from zope.container (plus tests). The intent is to allow packages that rely on these interfaces or the event classes to rely on zope.lifecycleevent (which has few dependencies) instead of zope.container (which has many). 3.5.1 (2009-03-09) ------------------ - Remove deprecated code and thus remove dependency on zope.deferredimport. - Change package's mailing list address to zope-dev at zope.org, as zope3-dev at zope.org is now retired. - Update package's description and documentation. 3.5.0 (2009-01-31) ------------------ - Remove old module declarations from classes. - Use zope.container instead of zope.app.container. 3.4.0 (2007-09-01) ------------------ Initial release as an independent package

zope.kgs-1.2.0-2.lbn19.noarch: Known-Good-Set (KGS) Support

zope.keyreference-4.1.0-1.lbn25.noarch: Object references that support stable comparison and hashes.

zope.intid-4.2.0-1.lbn25.noarch: This package provides an API to create integer ids for any object. Later objects can be looked up by their id as well. This functionality is commonly used in situations where dealing with objects is undesirable, such as in search indices or any code that needs an easy hash of an object.

zope.interface-4.4.2-1.lbn19.x86_64: This package provides an implementation of "object interfaces" for Python. Interfaces are a mechanism for labeling objects as conforming to a given API or contract. So, this package can be considered as implementation of the Design By Contract methodology support in Python.

zope.interface-4.0.1-4.lbn19.armv6hl: This package provides an implementation of "object interfaces" for Python. Interfaces are a mechanism for labeling objects as conforming to a given API or contract. So, this package can be considered as implementation of the Design By Contract methodology support in Python.

zope.index-4.2.0-1.lbn25.x86_64: Zope Cataloging and Indexing Framework Catalogs provide management of collections of related indexes with a basic search algorithm.

zope.index-3.6.4-1.lbn19.armv6hl: Zope Cataloging and Indexing Framework Catalogs provide management of collections of related indexes with a basic search algorithm.

zope.i18nmessageid-4.0.3-1.lbn19.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.i18nmessageid-3.5.3-1.lbn19.armv6hl: 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-4.3.1-1.lbn25.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.4.2-3.lbn25.noarch: This package contains support for editing HTML and XHTML inside a web page using the FCKeditor as a widget. This is a fairly simple application of FCKeditor, and simply instantiates a pre-configured editor for each widget. There are no options to control the editors individually. Detailed Documentation HTML file editing support This package contains support for editing HTML and XHTML inside a web page using the FCKeditor as a widget. This is a fairly simple application of FCKeditor, and simply instantiates a pre-configured editor for each widget. There are no options to control the editors individually. In creating this, we ran into some limitations of the editor that are worth being aware of. Noting these as limitations does not mean that other editors do any better; what’s available seems to be a mixed bag. The editor only deals with what can be contained inside a <body> element; anything that goes outside that, including the <body> and </body> tags, get lost or damaged. If there’s any way to configure FCKeditor to deal with such material, it isn’t documented. There’s no real control of the HTML source; whitespace is not preserved as a programmer would expect. That’s acceptable in many use cases, but not all. Applications should avoid using this widget if the original whitespace must be maintained.

zope.hookable-4.0.0-2.lbn19.armv6hl: 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.hookable-4.0.0-2.lbn19.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.4-1.lbn25.noarch: This package provides a global way to retrieve the currently active request object in a zope-based web framework.

« Previous 20 items Next 20 items » 1 ... 541 542 543 544 545 546 547 ... 2449


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

Sections

Modified items