-
five-0.1.0-1.lbn25.noarch
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
five.customerize-1.1-1.lbn25.noarch
TTW customization of template-based Zope 3 views
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
five.pt-2.2.4-1.lbn19.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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
ftw.bridge.client-1.0.7-1.lbn19.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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
ftw.bridge.proxy-1.1.1-4.lbn19.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).
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
