Modified items

All recently modified items, latest first.

plone4artists-calendar-2.0a3-6.lbn13.noarch: The p4a.calendar package is a package for producing calendars from collection of events. Features include: Monthly, Weekly, Daily view Any calendar activated (smart) folder can has several default views including a monthly, weekly and daily view. Chronological event view The events gathered together by the activated calendar can be displayed using a chronological event listing. Past events view Events that have already occurred are grouped into a past events listing page. Color coding by event type Events can be color coded based on what event type (keyword) they have been assigned.

plone4artists-audio-1.1rc1-3.lbn13.noarch: Upload a normal File to your Plone site, and Plone4ArtistsAudio will detect it as an MP3 or Ogg file and "decorate" it with metadata.

plone4artists-1.0.8-2.lbn13.noarch: Base p4a module

plone.z3cform-0.8.0-1.lbn13.noarch: plone.z3cform is a library that allows use of z3c.form with Zope 2 and the CMF.

plone.uuid-1.0.3-2.lbn13.noarch: UUIDs for content items

plone.transformchain-1.0.3-1.lbn13.noarch: Hook into repoze.zope2 that allows third party packages to register a sequence of hooks that will be allowed to modify the response before it is returned to the browser

plone.tiles-1.2-1.lbn13.noarch: For the purposes of this package, a tile is a browser view and an associated utility providing some metadata about that view. The metadata includes a title and description, an 'add' permission and optionally a schema interface describing configurable aspects of the tile. The idea is that a UI (such as Deco) can present the user with a list of insertable tiles and optionally render a form to configure the tile upon insertion. A tile is inserted into a layout as a link: <link rel="tile" target="placeholder" href="./@@sample.tile/tile1?option1=value1" /> The sub-path (tile1` in this case) is used to set the tile id attribute. This allows the tile to know its unique id, and, in the case of persistent tiles, look up its data. sample.tile is the name of the browser view that implements the tile. This is made available as the __name__ attribute. Other parameters may be turned into tile data, available under the data attribute, a dict, for regular tiles. For persistent tiles (those deriving from the PersistentTile base class), the data is fetched from annotations instead, based on the tile id. There are three interfaces describing tiles in this package: * IBasicTile is the low-level interface for tiles. It extends IBrowserView to describe the semantics of the __name__ and id attributes. * ITile describes a tile that can be configured with some data. The data is accessible via a dict called data. The default implementation of this interface, plone.tiles.Tile, will use the schema of the tile type and the query string (self.request.form) to construct that dictionary. This interface also describes an attribute url, which gives the canonical tile URL, including the id sub-path and any query string parameters. (Note that tiles also correctly implement IAbsoluteURL.) * IPersistentTile describes a tile that stores its configuration in object annotations, and is needed when configuration values cannot be encoded into a query string. The default implementation is in plone.tiles.PersistentTile. To make it possible to have several tiles of a given type on the same layout, the annotations are keyed by the tile __name__. In addition, tiles are described by ITileType, which contains attributes for the tile name, title, description, add permission and schema (if required). A properly configured tile, then, consists of a browser view providing IBasicTile or one of its derivatives, and a utility providing ITileType with the same name as the tile browser view. There is a convenience ZCML directive - <plone:tile /> - to register both of these components in one go. To support creation of appropriate tile links, plone.tiles.data contains two methods - encode() and decode() - to help turn a data dictionary into a query string and turn a request.form dict into a data dict that complies with a tile's schema interface.

plone.theme-2.1-2.lbn13.noarch

plone.testing-4.0.10-1.lbn13.noarch: Testing infrastructure for Zope and Plone projects.

plone.synchronize-1.0.1-2.lbn13.noarch: Simple decorators to support synchronized methods

plone.supermodel-1.2.4-1.lbn13.noarch: Integration layer making it possible to load schema definitions from XML

plone.subrequest-1.6.7-2.lbn13.noarch: Subrequests for Zope2

plone.stringinterp-1.0.11-1.lbn13.noarch: Adaptable string interpolation

plone.session-3.5.3-1.lbn13.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.schemaeditor-1.3.5-1.lbn13.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.scale-1.3.3-1.lbn13.noarch: Image scaling

plone.rfc822-1.1-1.lbn13.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.resourceeditor-1.0-1.lbn13.noarch: This package contains resources for integrating ACE (http://ace.ajax.org/) into Plone, with a file manager that can edit plone.resource resource directories in the ZODB. ACE can be found under ++resource++plone.resourceeditor/ace/*. The file manager can be included in a view with the following in the header: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/resources" /> and the following in the body: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/filemanager"> In both of these cases, resourceDirectory should be an in-ZODB plone.resource resource directory instance.

plone.resource-1.0.2-1.lbn13.noarch: plone.resource publishes directories of static files via the ZPublisher. These directories may be located either in the ZODB (as OFS folders and files), or on the filesystem. Each resource directory has a type and a name. When combined, these are used to traverse to the resource directory. For example: /++theme++mytheme/<subpath> /++sitelayout++mylayout/<subpath> /++templatelayout++mylayout<subpath>

plone.reload-2.0-2.lbn13.noarch: While being logged into the ZMI as an user with the Manager role visit /@@reload on your Zope application root via a browser. If your Zope is configured to listen on port 8080 on localhost this is: http://localhost:8080/@@reload If you get a Resource not found error, make sure you have loaded the configure.zcml file from this library and you really use the ZODB application root and not a Plone site as the base url. When you press the Reload Code button, all modules that have been changed since the last time they were loaded are reloaded. You'll get a status message telling you which modules have been reloaded. To reload all ZCML without a restart, press the 'Reload Code and ZCML' button. The action to perform is determined via a simple query string, so once you did a 'Reload Code' once, you can simply reload the browser page to execute the action once again. Caveats: There's some code structures which cannot be reloaded via the approach underlying this library. Plone portlets and content types are two examples of this. In general decorators will currently not always work.

« Previous 20 items Next 20 items » 1 ... 2366 2367 2368 2369 2370 2371 2372 ... 2425


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

Sections

Modified items