Search results

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.

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.

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.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).

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.builder-1.8.1-1.lbn19.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.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.calendar-2.1.0-1.lbn19.noarch

Calendar view based on fullcalendar

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.calendarwidget-1.1.11-1.lbn19.noarch

ftw.calendarwidget provides an archetypes calendar widget using the jQuery UI datepicker.