Search results

Products.kupu-1.5.2-3.lbn25.noarch

Kupu is a cross-browser WYWSIWYG editor. It allows the comfortable editing of the body of an HTML document. It's client-side (browser) requirements are one of: - Mozilla 1.3.1 or higher - Internet Explorer 5.5 or higher - Netscape Navigator 7.1 or higher - Opera 9 or higher Server-side there are hardly any requirements, except for some way of processing data (CGI or something more fancy like PHP, ASP or Python scripts in Zope). Kupu is particularly suited for content migration as well as editing. Content copied from an existing web page is pasted with all formatting intact. This includes structure such as headings and lists, plus links, image references, text styling, and other aspects. Copying text from a word processor with an HTML clipboard - such as MS Word - works exactly the same. Kupu will clean up the content before it is sent to the server, and can send data to the server asynchronously using PUT (which allows the data to be saved without reloading the page) as well as in a form. Kupu can be customized on many different levels, allowing a lot of changes from CSS, but also providing a JavaScript extension API.

buildout.dumppickedversions-0.5-2.lbn25.noarch

Dump buildout picked versions.

plone.app.content-2.1.7-1.lbn25.noarch

plone.app.content contains various views for Plone, such as folder_contents, as well as general content infrastructure, such as base classes and name choosers.

plone.app.controlpanel-2.3.11-1.lbn25.noarch

This package provides various control panels for Plone and some infrastrucuture to make it as easy as possible to create those with the help of zope.formlib. The general approach taken is to re-use as much of formlib as possible. This lead to the decision to use formlib's EditForm's functionality, as these provide the most automation found in formlib today. As a result of this decision we needed to take a slightly unconventional approach as EditForm's only work on one single context, as they are targeted at editing content objects, which usually are available as one context only. Control panels on the other side most commonly present settings from various sources and group these in a user-friendly way. In order to still be able to use EditForm's we introduce one abstract adapter as a middleware layer per control panel, that is used as the one context formlib's EditForm's need but internally pulls in the various settings from all the possible sources and pushes them back to the right places again. Following this approach a control panel consists of at least three classes: - An interface that describes the settings to be available in the control panel with the help of zope.schema. This gives us automatic type checking and some other basic validation of the settings. It also lets us specify vocabularies to be used for Choice-type properties. - An adapter implementing the above interface, exposing all the different settings as properties. As we don't want to have those control panels available all over the place, we restrict them to adapt the 'IPloneSiteRoot' only. Sometimes we use the 'SchemaAdapterBase' class from CMFDefault.formlib and the property wrapper 'ProxyFieldProperty' to automatically convert the values found in our site to the types expected by formlib and vica versa. For example we often need to store tuples while formlib expects sets, store encoded strings in site encoding rather than unicode or use Zope2's DateTime class instead of Python's datetime package. - And finally the form itself. We can use the common base class 'ControlPanelForm' to provide us with a consistent look and feel for all control panels. This is accomplished by using the 'control-panel.pt' template. For most cases this should be the only template that needs to be written. The 'ControlPanelForm' also provides us with two common actions and as a side effect overrides the 'handle_edit_action' in a Zope2-compatible way, where the default implementation needs the current locale to be present as part of the REQUEST, which is not the case in a Zope2 environment so far. The form is also the place to specify custom widgets for some properties. There are some custom widgets available in the widgets.py module in this package. While the above-mentioned works pretty well for simple cases it is not yet clear if it will work for complex control panels in the same way. Especially forms that use a multitude of actions (for example user/group management) or consist of more than one 'tab' (for example kupu but also smart folder settings) are not easily implemented so far. Hopefully we will be able to provide common helper classes and templates for those complex cases as well, though.

plone.app.event-1.2.7-1.lbn25.noarch

Plone.app.event is the calendaring framework for Plone. It provides Dexterity behaviors and an Archetypes type, Timezone support, RFC5545 icalendar export, Recurrence support, event views and a lot more. For a Dexterity event type using plone.app.event, use plone.app.contenttypes 1.1 or newer.

plone.app.mosaic-1.0b3-1.lbn25.noarch

Plone Mosaic is a new layout solution for Plone. It’s built for Plone 5, but should also work on Plone 4.3 with plone.app.widgets. Read this introduction and the package documentation for more details how to use this package. Concepts Mosaic, Blocks and Tiles provide a simple, yet powerful way to manage the pages on your Plone website. At their core, they rely on semantic HTML and resources with valid, publishable URLs. Mosaic Editor editor is a visual editor for pages rendered using Blocks. It relies on a grid system to place tiles onto a page in an intuitive, WYSIWYG, drag-and-drop manner. Using Mosaic Editor, it is easy to compose pages with complex, balanced and visually appealing layouts. - custom layout behavior for Dexterity content types Currently, the Mosaic Editor is activated, when any content with Custom layout view active is being edited. (Custom layout is available for any content with Layout support behavior enabled.) Blocks is a rendering algorithm based on HTML markup conventions. A page managed by Mosaic Editor is stored as a simple HTML document representing the actual content of that page as a standalone, publishable resource devoid of any site layout content (e.g. global navigation elements). This is referred to as content layout. Tiles represent the dynamic portions of a page. At its most basic level, a tile is simply an HTML document with a publishable URL. In practice, tiles are usually implemented as browser views deriving from the Tile base class and registered with the <plone:tile /> ZCML directive. This allows tiles to have some basic metadata and automatically generated edit forms for any configurable aspects , which Deco will expose to users. See plone.tiles for examples. When work with tiles in Mosaic Editor, there are three types of tiles: Text tiles Static HTML markup (WYSIWYG-edited text) placed into the content or site layout. Strictly speaking, text tiles are not tiles in that they do not involve any tile fetching or merging - instead they are stored as part of the page or site layout. To the user, however, a text tile can be moved around and managed like any other. Field tiles Render the value of a metadata field such as the title or description. The values of field tiles may be edited in-place in the page, but the value is stored in the underlying field and can be indexed in the catalog, used for navigation and so on. In practice, a field tile is an instance of the special tile plone.app.standardtiles.fields with the field name passed as a parameter. App tiles Any other type of dynamic tile. Examples may include a folder listing, a media player, a poll or pretty much anything else you can think of.

plone.app.portlets-2.5.6-1.lbn25.noarch

plone.app.portlets provides a Plone-specific user interface for plone.portlets, as well as a standard set of portlets that ship with Plone.

plone.app.standardtiles-1.0b4-1.lbn25.noarch

This package contains standard tiles to be used with Plone Mosaic (or as such with Plone Blocks composition).

plone.app.users-2.3.8-1.lbn25.noarch

This package provide the registration form for new users using z3c.form forms. It allows the site administrator to select fields from a schema to appear on the registration form.

plone.app.widgets-1.9.1-1.lbn25.noarch

The goal of plone.app.widgets is to provide an implementation for a new set of javascript widgets being developed in the Plone Mockup project. It overrides existing widgets used in dexterity and archetypes to provide tested and modularized widgets based on the concept of patterns. The widgets that are provided currently are: Adjust Text Size -- Easily change text size on a page. Cookie Directive -- A pattern that checks cookies enabled and asks permission for the user to allow cookies or not. Expose -- Exposes the focused element by darkening everything else on the page. Useful to focus the user attention on a particular area. Form Unload Alert -- A pattern to warn user when changes are unsaved and they try to navigate away from page. Live Search -- Dynamically query the server and display results. Modal -- Creates a modal dialog (also called overlay). Pick A Date -- Allows the user to select a date (with or without time) through a calendar. Picture -- A responsive image widget. Prevent Double Submit -- A pattern to prevent submitting a form twice. Query String for Collections -- A widget for creating query's for collections Related Items -- An advanced widget for selecting related items. Select2 -- Autocompletes, multiple or single selections from any kind of data source (with search!). Table Sorter -- A pattern you can apply to a table so it can have its items rearranged when clicking the header. TinyMCE (v4!!!) -- Rich text editor. Table of Contents -- Automatically generate a table of contents. Tooltip -- A pattern to show a tooltip on hover. DropZone -- Drag 'n drop file upload Widgets that are overridden in Edit forms are: subject language effectiveDate expirationDate contributrors creators relatedItems query All client side code (javascript/css/images) is done and tested as part of Plone Mockup project.