Personal tools
Skip to content. | Skip to navigation
plone.contentrules provides a "pure Zope 3" implementation of a rules engine which allows arbitary conditions and actions to be combined into rules, and rules to be executed dependent on events. You can think of this as somewhat similar to user-assembled mail filtering rules or something like Apple's Automator. It is used by plone.app.contentrules to provide such functionality for Plone.
Advanced i18n/l10n features useful in a CMS environment.
This package provides primitives to help delegate ZCatalog indexing operations to adapters. It doesn't do very much on its own, but can be used by catalog implementations that want to allow individual index values to be provided not by the object itself, but by separate adapters.
Abstract An extensible Plone JSON API Framework Introduction This Package allows Users to expose content information via JSON. Motivation This project was born in 2012, out of the need for a data source to build a network based iOS application. Or more precise, I wanted to learn iOS programming and wanted to knit my own JSON API:) I know, it is a little bit awkward to provide an own routing mechanism for Plone which dispatches the request after the ZPublisher did its job, but it worked and thus, I did it. Limitations Since the API comes after the ZPublisher, it can only make use of HTTP GET and HTTP POST methods. The other methods will never reach the API View. Be aware that the API View comes with the permission zope2.View, so you need to programmatically check for the correct permissions on your custom routes.
Introduction This is an add-on package for plone.jsonapi.core which provides some basic URLs for Plone standard contents (and more). Motivation The routes package is built on top of the plone.jsonapi.core package to allow Plone developers to build modern (JavaScript) web UIs which communicate through a RESTful API with their Plone site. Compatibility The plone.jsonapi.routes should work with Plone 3 and 4. API URL After installation, the Plone API routes are available below the plone.jsonapi.core root URL (@@API) with the base /plone/api/1.0, for example http://localhost:8080/Plone/@@API/plone/api/1.0/api.json. There is also an overview of the registered routes which can be accessed here: http://localhost:8080/Plone/@@API/plone/api/1.0/api.json API Routes BASE_URL: /plone/api/1.0 This is an overview of the provided API Routes. The basic content routes provide all an interface for CRUD operations. CRUD URL Scheme: OPERATION URL METHOD PAYLOAD VIEW <BASE_URL>/<RESOURCE>/<uid:optional> GET -- CREATE <BASE_URL>/<RESOURCE>/create/<uid:optional> POST JSON UPDATE <BASE_URL>/<RESOURCE>/update/<uid:optional> POST JSON DELETE <BASE_URL>/<RESOURCE>/delete/<uid:optional> POST JSON
*plone.keyring* contains a Zope3 utility that facilitates handling of secrets in an application. Secrets are very important in modern applications, which is why a shared tool to manage them is useful. plone.keyring contains two basic components: * a *keyring*: a data structures which contains one or more secrets. * a *key manager*: a utility which contains the available keyrings and provides some convenience methods to manage them Keyrings ======== The keyring is the workhorse: it contains a set of secrets for a specific purpose. A ring has room for a fixed number of secrets which is set at creation time. The most recently added secret is considered to be the 'current' secret and the one that should be used. Older secrets in the ring can be used to keep data generated with older secrets valid for a period of time. Key manager =========== The key manager is a container for the available keyrings. It always contains a default system keyring which is used when no other ring is explicitly requested.
by Raphael Ritz, Jeff Roche, Martin Aspeli and others Provides basic automatic locking support for Plone. Locks are stealable by default, meaning that a user with edit privileges will be able to steal another user's lock, but will be warned that someone else may be editing the same object. Used by Plone, Archetypes and plone.app.iterate Basic locking ------------- By default, this is enabled on any ITTWLockable object. By default, this applies to any Archetypes content object. Stealable locks --------------- By default, locks can be stolen. That is, if a particular user has a lock and another user (with edit rights over the object) wants to edit the object, the second user can unlock the object. This is opposed to "safe" unlocking, which is done by the original owner. Categorised locks ----------------- So far, we have been managing a single type of lock. However, it is possible to manage different types of locks which are mutually exclusive. For example, if a particular type of lock is applied, it cannot be stolen by a user who is attempting to create another type of lock. Anonymous locking ================= When we are anonymous but do have edit rights we can also do a lock. Locking timeouts ================ Lock timeout should be ten minutes by default Turning locking on or off ========================= The status of the entire TTW locking mechanism can be controlled by setting up an ILockSettings adapter with a lock_on_ttw_edit property.
plone.memoize provides Python function decorators for caching the values of functions and methods. The type of cache storage is freely configurable by the user, as is the cache key, which is what the function's value depends on. plone.memoize has support for memcached and is easily extended to use other caching storages. It also has specialized decorators for use with Zope views. However, plone.memoize can be used without Zope.
This package contains a unittest test class based on the one from the Mocker mock library (http://labix.org/mocker). This class provides support for registering Zope 3 components (utilities, adapters, subscription adapters and event handlers) from mocks and tearing down the global component registry during test tear-down. There are also a few convenience methods and parameter checkers that are useful to Zope and Plone testing.