Search results

python2-zope.hookable-4.2.0-10.lbn25.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.

python2-zope.hookable-4.2.0-10.lbn25.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.

python2-zope.i18nmessageid-4.3.1-1.lbn25.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.

python2-zope.i18nmessageid-4.3.1-1.lbn25.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.

python2-zope.interface-5.1.0-1.lbn25.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.

python2-zope.interface-4.6.0-10.lbn25.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.

python2-zope.lifecycleevent-4.3-2.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.

python2-zope.location-4.2-1.lbn19.noarch

zope.location :target:

python2-zope.location-4.2-1.lbn25.noarch

In Zope3, location are special objects that has a structural location.

python2-zope.proxy-4.3.1-10.lbn25.x86_64

Proxies are special objects which serve as mostly-transparent wrappers around another object, intervening in the apparent behavior of the wrapped object only when necessary to apply the policy (e.g., access checking, location brokering, etc.) for which the proxy is responsible. Editorial note: Unfortunately, we don't have separate documentation for zope.proxy at this time. This is a shame because they are generically useful. We are publishing this release without documentation mainly because it is a dependency of other releases.