Modified items

All recently modified items, latest first.

ftw.publisher.core-2.3.3-1.lbn13.noarch: The ftw.publisher packages provide tools for publishing plone contents from one instance to another. This package provides shared tools and utils used by ftw.publisher.sender and ftw.publisher.receiver.

ftw.dictstorage-1.2-3.lbn13.noarch: This package provides a layer for storing key / value paires. The storage can be configured dinamically by providing a IConfig adapter of the context on which the dict storage is used.

ftw.dashboard.portlets.postit-1.3.4-1.lbn13.noarch: How to use ftw.dashboard.postit ================================== 1.) Install the ftw.dashboard.portlets.postit product with the portal_setup tool. 2.) add a postit portlet to your dashboard 3.) create notes ... Description: ============ the postit portlet is a usefull plone 3 portlet for your dashboard. The adding and removing function are ajax implemented (jquery).

ftw.dashboard.dragndrop-1.5.3-1.lbn13.noarch: ftw.dashboard.dragndrop adds persistent dragndrop functionality to the standard plone dashboard. http://onegov.ch/approved.png/image Certified: 01/2013 Features: Drag'n'drop: All dashboard portlets can be moved with drag'n'drop from column to column and reordered in the column. Folding: Dashboard porlets are foldable. Edit portlet icon: Dashboard portlets have an icon on the top (pencil) for editing the portlet. close/remove portlet: Dashboard portlets have an icon on the top (cross) for removing the portlet from the dashboard.

ftw.dashboard-1.3.4-1.lbn13.noarch: ftw.dashboard module

ftw.bridge.proxy-1.1.1-4.lbn13.noarch: ftw.bridge.proxy is a small pyramid based web application for proxying requests between multiple plone instances. It's purpose is to isolate the plone instances by routing through this proxy. This allows to easily move plone instances to other servers. Maintenance mode Each configured client (plone site) can be switched into maintenance mode on the bridge. When maintenance mode is enabled, the bridge answers every request to this client with a HTTP 503 (Service Unavailable). The maintenance mode can be enabled in the manage view of the bridge (/manage).

ftw.bridge.client-1.0.7-1.lbn13.noarch: The ftw.bridge tools are used for communication between several Plone instances. It is also possible to cummuncate with other web services. Requests between web services are proxied through the ftw.bridge.proxy. This makes it possible to move or reconfigure certain dependent webservices (clients) only by reconfiguring the proxy. The clients do not know where other target clients are located - they only communicate with the proxy directly, which forwards the requests to the target client. Features ftw.bridge.client integrates ftw.bridge support into Plone. It provides tools and utilities for communication and authentication. * Authentication: A PAS plugin authenticates requests and logs the user in on the target client without transmitting his password. Only requests from the configured ftw.bridge.proxy are authenticated. * Requests: The IBridgeRequest utility is used for making requesting other clients. It is also able to make remote catalog queries and transmitting the result brains to the sources by using fake brains. * Brain transport: By using a BrainRepresentation it is possible to get brains from a remote client. A BrainSerializer utility serializes and deserializes all brain metadata so that they can be used on the source client. * Watcher portlet: A recently-modified portlet can be used for generic listing a list of recently modified objects on the remote client but it is also possible to list other links. There is a browser view @@watch which creates a recently-modified portlet on the remote client dashboard. The watcher portlet loads its data asynchronously using javascript for not blocking while loading the dashboard. * Favorites: A browser view @@remote-add-favorite adds the context to the favorites on the remote client dashboard.

five.pt-2.2.1-2.lbn13.noarch: This package brings the Chameleon template engine to the Zope 2 platform. Five is supported. It works using monkey-patching onto the existing API (specifically, the TALInterpreter and PageTemplate classes). In simple terms, what the patching does is to replace the TAL interpreter class and make sure that the so-called "cooking" routine uses the Chameleon parser and compiler instead of the zope.* reference implementation.

five.localsitemanager-2.0.5-2.lbn13.noarch: five.localsitemanager attempts to provide a local site manager implementation that is as close to Zope 3's implementation as possible. Some reservations that do not conflict with Zope 3 have been made to ease the path with CMF.

five.intid-1.0.3-2.lbn13.noarch: s package makes it possible to use zope.app.intid (and consequentually other packages that rely on it such as zope.app.keyreference) in a Zope2 environment.

five.grok-1.3.2-1.lbn13.noarch: five.grok is a development layer for Zope 2, based on Grok framework concepts. The development techniques are similar to the ones used with Grok framework. It is based on grokcore namespace packages that were factored out of Grok framework. Implemented features Coming from Grok, the following components are available to Zope 2 developers: * Zope 3 Component (Adapter, Global utilities, Subscribers), * Permissions, * Views and Viewlets, * Skins and resources directories, * Page Templates (using the Zope 2 Page Templates), * Formlib forms, * Local sites and local utilities, * Annotations.

five.globalrequest-1.0-2.lbn13.noarch: Zope 2 integration for zope.globalrequest

five.formlib-1.0.4-3.lbn13.noarch: five.formlib

five.customerize-1.1-1.lbn13.noarch: TTW customization of template-based Zope 3 views

five-0.1.0-1.lbn13.noarch

dm.reuse-1.1-3.lbn13.noarch: Support for object reuse with slight modifications

dm.profile-1.0-2.lbn13.noarch: Easier readable profile statistics -- especially for caller and callee analysis

dm.incrementalsearch-2.0-2.lbn13.x86_64: dm.incrementalsearch is an efficient low level search execution engine. Its primary purpose is to incrementally perform searches involving and, or and not queries over ZODB.BTrees. Incrementally means here that hits are determined one at a time: the first hit, then the second hit, then the third hit, etc. Therefore, the first few hits can be determined extremely fast. But even if all hits need to be determined, the incremental execution of subqueries can lead to speedups of several orders for some query types (especially those dominated by specific and queries). Queries involving large or subqueries are difficult to optimize in the standard way. But often they can be replaced by incremental filtering. With this technique, a subquery is removed from the original search, the modified search executed and the result filtered by the removed subquery. incrementalsearch supports incremental filtering and thereby can again gain serveral orders of speedup for otherwise difficult to treat query types. The primary concept is that of an ISearch (incremental search). This is conceptionally a sorted list, computed incrementally (or lazily). The elements of this list are the ISearch's hits. The ISearch's keytype determines the type of the list elements. Currently supported are OBJECT (comparable Python objects), INT (Python 32 bit integers) and LONG (Python 64 bit integers).

dataflake.ldapconnection-1.5-1.lbn13.noarch: This package provides an abstraction layer on top of python-ldap. It offers a connection object with simplified methods for inserting, modifying, searching and deleting records in the LDAP directory tree. Failover/redundancy can be achieved by supplying connection data for more than one LDAP server.

dataflake.cache-1.4-1.lbn13.noarch: This package provides a set of simple cache implementations for use in Python code. Its roots are in the internally-used SimpleCache module from Products.LDAPUserFolder.

« Previous 20 items Next 20 items » 1 ... 2312 2313 2314 2315 2316 2317 2318 ... 2359


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

Sections

Modified items