Search results

plone.rfc822-1.1.4-1.lbn25.noarch

This package provides primitives for turning content objects described by zope.schema fields into RFC (2)822 style messages, as managed by the Python standard library's email module. It consists of: * A marker interface IPrimaryField which can be used to indicate the primary field of a schema. The primary field will be used as the message body. * An interface IFieldMarshaler which describes marshalers that convert to and from strings suitable for encoding into an RFC 2822 style message. These are adapters on (context, field), where context is the content object and field is the schema field instance. * Default implementations of IFieldMarshaler for the standard fields in the zope.schema package. * Helper methods to construct messages from one or more schemata or a list of fields, and to parse a message and update a context object accordingly.

plone.scale-2.1-2.lbn25.noarch

This package contains image scaling logic for use in Zope environments. It supports Zope 2, grok and other systems build on using the Zope ToolKit (ZTK). Several design goals were used when writing this package: image scaling to any width, height, width&height should be supported using both up-scaling and down-scaling. Scaling parameters should never be fixed in code. This allows designers to use any image scale they want without having to modify python code. the result of scaling will be an image along with its new size, not a HTML or XHTML tag. We already have excellent tools to generate tags in the form of Zope Pagetemplates, Genshi and other template languages that are much better suited for this purpose. In addition several implementation goals were defined: image scaling must happen on demand instead of up-front. This reduces initial save time and prevents unnecessary scalings from being generated. image scaling parameters should not be part of the generated URL. Since the number of parameters can change and new parameters may be added in the future this would create overly complex URLs and URL parsing. no HTML rewriting (such as done by repoze.bitblt) should be required. it should be possibly to develop an external storage system which stores scaled images externally and returns a URL which bypasses the application server. This should be configurable via just a filesystem path & base URL. minimum number of external dependencies, allowing this package to be used in many environments. testable without requiring zope.testing. Running setup.py test should be sufficient. URLs for scaled images should have an extension which reflects their MIME type. This is facilitates cache (and other front-end services) configuration.

plone.schema-1.2.0-1.lbn25.noarch

Plone specific extensions and fields for zope schematas.

plone.schemaeditor-2.0.9-1.lbn25.noarch

plone.schemaeditor provides a through-the-web interface for modifying Zope 3 schemata (interfaces). Currently there is support for: * adding and removing fields * editing attributes of existing fields * reordering fields * renaming fields plone.schemaeditor only handles the actual schema editing. To be useful, it requires some integration code to take care of the following pieces: * traversing to a schema that is used as the context of the editor * persisting schema changes across Zope restarts See plone.app.dexterity (along with plone.dexterity and plone.supermodel) for one approach to this integration. The following field types (from zope.schema) are currently supported: * TextLine * Text * Int * Float * Bool * Password * Datetime * Choice (with simple list of values) * List of Choice (with simple list of values) Third-party packages can make additional field types available by registering new IFieldFactory utilities.

plone.session-3.6.2-1.lbn25.noarch

plone.session implements secure session management for Zope sites. It can be used directly, or be used as a base for custom session management strategies. In its default configuration plone.sessions uses a secure cryptographic hash based on HMAC_ SHA-1_ to authenticate sessions. The hash is generated using the users login name and a secret stored in the PAS plugin. This has several advantages over other session management systems: * passwords are not send to the server in a cookie on every request, as is done by the *Cookie Auth Helper* * it does not require any ZODB write for sessions, as is needed by the *Session Crumbler*. This allows it to scale very well. * it allows you to invalidate all existing authentication cookies for users by updating the secret. Normally a session cookie is used to track sessions; that means that as long as a user keeps his browser open (and does not explicitly log out) the session remains opens. This can be changed by setting the ``cookie_lifetime`` property of the plugin to the number of seconds the cookie should remain valid *after the moment of login*. Using plone.session ------------------- plone.session only takes care of handling sessions for already authenticated users. This means it can not be used stand-alone: you need to have another PAS plugin, such as the standard *Cookie Auth Helper* to take care of authentication. After a user has been authenticated plone.session can take over via the PAS *credentials update* mechanism. Using custom session authentication ----------------------------------- plone.session delegates the generation and verification of sessions to an ISessionSource adapter. This adapter adapts the PAS plugin and implements four methods: createIdentifier Return an identifier for a userid. An identifier is a standard python string object. verifyIdentifier Verify if an identity corresponds to a valid session. Returns a boolean indicating if the identify is valid. extractLoginName Extract the login name from an identifier. invalidateSession Mark a session for a principal as invalid. A source may not support this, in which case it should return False. plone.session ships with two example adapers: hash and userid. The userid adapter is a trivial example which uses the userid as session identifier. This is very insecure since there is no form of verification at all. DO NOT USE THIS ADAPTER IN YOUR SITE! The hash plugin creates a random secret string which is stored as an attribute on your plugin. It uses this secret to create a SHA1 signature for the user id with the secret as session identifier. This approach has several good qualities: * it allows us to verify that a session identifier was created by this site * there is no need to include passwords in the session idenfitier * it does not need to store anything in Zope itself. This means it works as-is in ZEO setups and can scale very well. There are a few downsides to this approach: * if a users password is changed or disabled session identifiers will continue to work, making it hard to lock out users

plone.stringinterp-1.2.1-1.lbn25.noarch

Provides ${id} style string interpolation using named adapters to look up variables. This is meant to provide a trivially simple template system for clients like plone.app.contentrules. To interpolate a string in context, just follow the pattern: from plone.stringinterp.interfaces import IStringInterpolator IStringInterpolator(context)("Here is the title: ${title}") Substitution of variables that are part of the Dublin Core are provided with the package. To provide additional substitutions, just provide a named adapter implementing interfaces.IStringSubstitution for your context. The adapter name is used for the lookup. You can also wrap your context with IContextWrapper adapter if you need to pass custom messages within your substitutions.

plone.subrequest-1.8.7-1.lbn19.noarch

plone.subrequest provides a mechanism for issuing subrequests under Zope2.

plone.supermodel-1.3.0-1.lbn25.noarch

plone.supermodel provides XML import and export for schema interfaces based on zope.schema fields. The principal use cases are: 1. Define a schema interface in code based on an XML file. This can be done with syntax like: >>> from plone.supermodel import xmlSchema >>> IMySchema = xmlSchema("myschema.xml") 2. Save and load interface definitions via an XML format. To turn a schema interface into XML, you can do: >>> from plone.supermodel import serializeSchema >>> xml_string = serializeSchema(IMySchema) To get a schema from an XML file, you can use the xmlSchema() function above, or you can use the more powerful spec() function, which turns a dict of all schemata and widget hints in a given XML file. See schema.txt and interfaces.py in the source code for more information, including details on how to give widget hints for forms and how to keep multiple schemata in the same XML file. Supermodel vs. Userschema This package is quite similar to Tres Seaver's "userschema" library, which can be found at http://agendaless.com/Members/tseaver/software/userschema. In fact, plone.supermodel was originally based on userschema. However, as the package was refined and refactored, less and less of userschema remained, to the point where we'd have needed to significantly refactor the latter to keep using it. The XML import/export code is currently based on algorithms that were written for plone.app.portlets and plone.app.contentrules' GenericSetup handlers. Some of the key differences between the two packages are: userschema can create schema interfaces from HTML forms and CSV spreadsheets. plone.supermodel does not support such configuration. Schemata created with userschema are typically loaded at startup, with a ZCML directive. plone.supermodel supports a "pseudo-base class" syntax, as seen above, to define interfaces in Python code. Beyond that, its API is more geared towards runtime configuration. plone.supermodel supports serialisation of schemata to XML. The plone.supermodel XML syntax is more directly tied to zope.schema fields, and infers most parameters from the schema interface declared by each zope.schema field. This has two advantages: API documentation for zope.schema can be easily applied to <schema /> blocks New fields and obscure attributes are easier to support plone.supermodel's XML schema is intended to support more schema metadata, including widget hints.

plone.synchronize-1.0.4-1.lbn19.noarch

This package provides a simple decorator to help synchronize methods across threads, to avoid problems of concurrent access.

plone.testing-5.1-1.lbn25.noarch

plone.testing provides tools for writing unit and integration tests in a Zope and Plone environment. It is not tied to Plone, and it does not depend on Zope 2 (although it has some optional Zope 2-only features). plone.testing builds on zope.testing, in particular its layers concept. This package also aims to promote some “good practice” for writing tests of various types. Note If you are working with Plone, there is a complementary package plone.app.testing, which builds on plone.testing to provide additional layers useful for testing Plone add-ons.