Modified items

All recently modified items, latest first.

zope.preference-3.8.0-2.lbn25.noarch: User Preferences Framework

zope.pluggableauth-2.1.0-2.lbn25.noarch: Based on zope.authentication, this package provides a flexible and pluggable authentication utility, and provides a number of common plugins. Pluggable-Authentication Utility The Pluggable-Authentication Utility (PAU) provides a framework for authenticating principals and associating information with them. It uses plugins and subscribers to get its work done. For a pluggable-authentication utility to be used, it should be registered as a utility providing the zope.authentication.interfaces.IAuthentication interface. Authentication The primary job of PAU is to authenticate principals. It uses two types of plug-ins in its work: Credentials Plugins Authenticator Plugins Credentials plugins are responsible for extracting user credentials from a request. A credentials plugin may in some cases issue a ‘challenge’ to obtain credentials. For example, a ‘session’ credentials plugin reads credentials from a session (the “extraction”). If it cannot find credentials, it will redirect the user to a login form in order to provide them (the “challenge”). Authenticator plugins are responsible for authenticating the credentials extracted by a credentials plugin. They are also typically able to create principal objects for credentials they successfully authenticate. Given a request object, the PAU returns a principal object, if it can. The PAU does this by first iterating through its credentials plugins to obtain a set of credentials. If it gets credentials, it iterates through its authenticator plugins to authenticate them. If an authenticator succeeds in authenticating a set of credentials, the PAU uses the authenticator to create a principal corresponding to the credentials. The authenticator notifies subscribers if an authenticated principal is created. Subscribers are responsible for adding data, especially groups, to the principal. Typically, if a subscriber adds data, it should also add corresponding interface declarations.

zope.password-4.2.0-2.lbn25.noarch: This package provides a password manager mechanism. Password manager is an utility object that can encode and check encoded passwords.

zope.pagetemplate-4.4.1-1.lbn25.noarch: Page Templates provide an elegant templating mechanism that achieves a clean separation of presentation and application logic while allowing for designers to work with templates in their visual editing tools (FrontPage, Dreamweaver, GoLive, etc.). Detailed Documentation ZPT (Zope Page-Template) Architecture There are a number of major components that make up the page-template architecture: The TAL compiler and interpreter. This is responsible for compiling source files and for executing compiled templates. See the zope.tal package for more information. An expression engine is responsible for compiling expressions and for creating expression execution contexts. It is common for applications to override expression engines to provide custom expression support or to change the way expressions are implemented. The zope.app.pagetemplate package uses this to implement trusted and untrusted evaluation; a different engine is used for each, with different implementations of the same type of expressions. Expression contexts support execution of expressions and provide APIs for setting up variable scopes and setting variables. The expression contexts are passed to the TAL interpreter at execution time. The most commonly used expression implementation is that found in zope.tales. Page templates tie everything together. They assemble an expression engine with the TAL interpreter and orchestrate management of source and compiled template data. See zope.pagetemplate.interfaces.

zope.modulealias-3.4.0-4.lbn25.noarch: Zope modulealias

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.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.lbn25.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.6.0-2.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.

zope.interface-4.6.0-2.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.

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-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.i18nmessageid-4.1.0-1.lbn25.py37.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.

« Previous 20 items Next 20 items » 1 ... 632 633 634 635 636 637 638 ... 2449


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

Sections

Modified items