Modified items

All recently modified items, latest first.

ftw.calendar-3.1.0-1.lbn25.noarch: Features Generic: ftw.calendar doesn’t care about the event objects, it only needs a collection in which the resulting brains have a start and a end attribute. If the calendar view is on an other content type than a collection, it will show all events (types defined in portal_calendar) below this context. Lightweight: the only requirement (apart from plone of course) is simplejson. Optionally, if you want to enable resizing of events and the drag and drop functionality, you can install jquery.ui but it is not required. Internationalized: currently ftw.calendar is available in german, english and czech. Feel free to add more translations. Integrated: ftw.calendar cares about your calendar settings. First day of the week is respected and displayed accordingly. Flexible: The calendar source is implemented as an adapter. Override it to modify the title or add css classes.

ftw.builder-1.8.1-1.lbn25.noarch: Create Plone objects in tests with the Builder Pattern. The builder pattern simplifies constructing objects. In tests we often need to create Plone objects, sometimes a single object, sometimes a whole graph of objects. Using the builder pattern allows us to do this in a DRY way, so that we do not repeat this over and over.

ftw.bridge.proxy-1.1.1-4.lbn25.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.lbn25.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.4-2.lbn25.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.6-1.lbn25.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.1.2-1.lbn25.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-2.lbn25.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-3.lbn25.noarch: This package integrates zope.globalrequest with Zope 2. It is compatible with Zope 2.12 and later. In Zope 2.10, you can install ZPublisherEventsBackport to use it. The only thing you need to do to use this package is to load its configuration from your own ZCML file: <include package="five.globalrequest" /> You can now use zope.globalrequest as normal: from zope.globalrequest import getRequest request = getRequest() The request is set up when publication starts, when the IPubStart event is fired. It is cleared on one of the IPubEnd events: IPubSuccess or IPubFailure. If you have your own event handlers for either of these events, you should be aware that the event setup/clear could happen after/ before your own event handler is executed, since the order of execution for event handlers is not controllable.

five.formlib-1.0.4-5.lbn25.noarch: five.formlib provides integration of the zope.formlib and zope.app.form packages into the Zope2 application server.

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

five-0.1.0-1.lbn25.noarch

borg.localrole-3.1.3-1.lbn25.noarch: This PAS_ plug-in can be used to assign local roles in a particular context, by adapter. It can be installed via the GenericSetup_ profile in this product.

borg-3.1.3-1.lbn25.noarch: borg python module

archetypes-1.7.3-1.lbn25.noarch: archetypes base module hierarchy

Products.validation-2.0.2-1.lbn25.noarch: Data validation package for Archetypes.

Products.statusmessages-4.1.2-1.lbn25.noarch

Products.slideshowfolder-4.1b1-1.lbn25.noarch: Slideshow Folder provides a simple, elegant animated slideshow for Plone. Slideshow Folder integrates the Slideshow for Mootools javascript class into Plone. This powerful, lightweight, well-designed slideshow module was originally developed for TextPattern and has also been adapted for Joomla. Slideshow Folder offers the following features: * Animated slideshows with configurable transitions, including fade, wipe and push. * Configurable duration of transitions, and slide timing * Pan and zoom over slides (aka the "Ken Burns" effect) * Thumbnail navigation and forward/back arrows (both are optional) * Image captions * Intelligent preloading of images to save bandwidth

Products.jsImagePopups-2.0b8-1.lbn25.noarch: Products.jsImagePopups provides a jQuery lightbox plugin to open image popups without using a new browser window. By default links pointing to *image_view_fullscreen*, having a *rel* attribute beginning with *lightbox* or contained in an element with class *photoAlbumEntry* are using the provided plugin. This includes the *news item* view the *album* view and the *image* of plone. To activate the plugin for your own view either set the *rel* attribute on the desired links or instantiate the links on your own, for an example on how to do this have a look at the *browser/lightbox.init.js* file. Changing the behaviour of the lightbox may be done by changing the *jsImagePopups* property in the *site_properties* property sheet or by activating the plugin by yourself and providing a custom settings object.

Products.i18ntestcase-1.4.0-1.lbn25.noarch: Products.i18ntestcase is build on top of the ZopeTestCase package. It has been developed to simplify testing of gettext i18n files for Zope products. (c) 2005-2008, Hanno Schlichting (plone@hannosch.info) License: GPL Products.i18ntestcase Readme Products.i18ntestcase is build on top of the ZopeTestCase package. It has been developed to simplify testing of gettext i18n files for Zope products. The Products.i18ntestcase package provides: * The class 'I18NTestCase' of which you can derive your own test cases. * The classes 'PoTestCase.py' and 'PotTestCase.py' which include a set of common tests for po and pot files. * The 'test_i18n.py' script, which you can put in your tests folder to easily use all these already written tests. Copying the test_i18n.py to your tests folder is the preferred way.

« Previous 20 items Next 20 items » 1 ... 650 651 652 653 654 655 656 ... 2449


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

Sections

Modified items