Modified items

All recently modified items, latest first.

zope.sendmail-4.0.1-2.lbn25.noarch: zope.sendmail is a package for email sending from Zope 3 applications. Email sending from Zope 3 applications works as follows: A Zope 3 application locates a mail delivery utility (IMailDelivery) and feeds a message to it. It gets back a unique message ID so it can keep track of the message by subscribing to IMailEvent events. The utility registers with the transaction system to make sure the message is only sent when the transaction commits successfully. (Among other things this avoids duplicate messages on ConflictErrors.) If the delivery utility is a IQueuedMailDelivery, it puts the message into a queue (a Maildir mailbox in the file system). A separate process or thread (IMailQueueProcessor) watches the queue and delivers messages asynchronously. Since the queue is located in the file system, it survives Zope restarts or crashes and the mail is not lost. The queue processor can implement batching to keep the server load low. If the delivery utility is a IDirectMailDelivery, it delivers messages synchronously during the transaction commit. This is not a very good idea, as it makes the user wait. Note that transaction commits must not fail, but that is not a problem, because mail delivery problems dispatch an event instead of raising an exception. However, there is a problem – sending events causes unknown code to be executed during the transaction commit phase. There should be a way to start a new transaction for event processing after this one is commited. An IMailQueueProcessor or IDirectMailDelivery actually delivers the messages by using a mailer (IMailer) component that encapsulates the delivery process. There currently is only one mailer: ISMTPMailer sends all messages to a relay host using SMTP.

zope.securitypolicy-4.1.0-1.lbn25.noarch: This package implements a role-based security policy similar to the policy found in Zope 2. The security policy is responsible for deciding whether an interaction has a permission on an object. This security policy does this using grant and denial information. Managers can grant or deny: roles to principals, permissions to principals, and permissions to roles

zope.security-4.0.3-1.lbn19.x86_64: The Security framework provides a generic mechanism to implement security policies on Python objects. This introduction provides a tutorial of the framework explaining concepts, design, and going through sample usage from the perspective of a Python programmer using the framework outside of Zope.

zope.security-3.8.3-2.lbn19.armv6hl: The Security framework provides a generic mechanism to implement security policies on Python objects. This introduction provides a tutorial of the framework explaining concepts, design, and going through sample usage from the perspective of a Python programmer using the framework outside of Zope.

zope.schema-4.9.3-1.lbn19.noarch: ============== Zope 3 Schemas ============== Introduction ------------ Schemas extend the notion of interfaces to detailed descriptions of Attributes (but not methods). Every schema is an interface and specifies the public fields of an object. A *field* roughly corresponds to an attribute of a python object. But a Field provides space for at least a title and a description. It can also constrain its value and provide a validation method. Besides you can optionally specify characteristics such as its value being read-only or not required. Zope 3 schemas were born when Jim Fulton and Martijn Faassen thought about Formulator for Zope 3 and PropertySets while at the Zope 3 sprint at the Zope BBQ in Berlin. They realized that if you strip all view logic from forms then you have something similar to interfaces. And thus schemas were born.

zope.rdb-3.5.0-2.lbn25.noarch: Zope RDBMS transaction integration

zope.ramcache-2.2.0-1.lbn25.noarch: This package provides a RAM-based cache implementation for Zope.

zope.publisher-4.3.2-1.lbn25.noarch: zope.publisher allows you to publish Python objects on the web. It has support for plain HTTP/WebDAV clients, web browsers as well as XML-RPC and FTP clients. Input and output streams are represented by request and response objects which allow for easy client interaction from Python. The behaviour of the publisher is geared towards WSGI compatibility.

zope.ptresource-4.0.0-1.lbn25.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 a “page template” resource class, a resource which content is processed with Zope Page Templates engine before returning to client. The resource factory class is registered for “pt”, “zpt” and “html” file extensions in package’s configure.zcml file.

zope.proxy-devel-4.2.0-3.lbn19.x86_64: This package provides the support files which can be used to build applications using the Zope proxy infrastructure

zope.proxy-4.2.0-3.lbn19.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.

zope.proxy-3.6.1-2.lbn19.armv6hl: 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.

zope.processlifetime-2.1.0-1.lbn25.noarch: This package provides interfaces / implementations for events relative to the lifetime of a server process (startup, database opening, etc.) It is derived from Zope 3.4’s zope.app.appsetup.

zope.principalregistry-3.7.1-2.lbn25.noarch: zope.principalregistry

zope.principalannotation-4.1.1-1.lbn25.noarch: This package implements annotations for zope.security principals. Common annotation techniques, like AttributeAnnotations cannot be applied to principals, since they are created on the fly for every request. Principal Annotations This package implements annotations for zope.security principals. To make it clear, the principal here is the object that provides zope.security.interfaces.IPrincipal interface and annotations is the object providing zope.annotation.interfaces.IAnnotations. The problem is that principals is dynamic, non-persistent objects created on the fly for every security participation (request or something), so common annotation techniques, like AttributeAnnotations cannot be applied to them. This package provides a persistent storage of principal annotations, storing annotations by principal ID as well as an adapter from IPrincipal to IAnnotations.

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

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


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

Sections

Modified items