Search results

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.

plone.formwidget.recaptcha-2.0a2-1.lbn25.py37.noarch

ReCaptcha widget for Plone.

plone.releaser-1.5.3-1.lbn25.py37.noarch

Plone release management utilities

plone.rest-1.0b1-1.lbn25.noarch

plone.rest allows you to use HTTP verbs such as GET, POST, PUT, DELETE, etc. in Plone. REST stands for Representational State Transfer. It is a software architectural principle to create loosely coupled web APIs. plone.rest provides the basic infrastructure that allows us to build RESTful endpoints in Plone. The reason for separating this infrastructure into a separate package from the ‘main’ full Plone REST API is so you can create alternative endpoints tailored to specific usecases. A number of these specific endpoints are already in active use. Audience plone.rest is for experienced web developers who want to build their own HTTP/REST endpoints on top of Plone. If you want to use a ready-made full RESTful Plone API, you should use plone.restapi. That package uses, and depends upon, this one. Features Registering RESTful service endpoints for the following HTTP verbs: GET POST PUT DELETE PATCH OPTIONS Support for Dexterity and Archetypes-based content objects Content negotiation (‘application/json’ is currently the only format supported). Named services allows to register service endpoints for custom URLs Registering RESTful Service Endpoints plone.rest allows you to register HTTP verbs for Plone content with ZCML.

plone.session-3.6.2-1.lbn25.noarch

plone.session implements secure session management for Zope sites. It can be used directly, or be used as a base for custom session management strategies. In its default configuration plone.sessions uses a secure cryptographic hash based on HMAC_ SHA-1_ to authenticate sessions. The hash is generated using the users login name and a secret stored in the PAS plugin. This has several advantages over other session management systems: * passwords are not send to the server in a cookie on every request, as is done by the *Cookie Auth Helper* * it does not require any ZODB write for sessions, as is needed by the *Session Crumbler*. This allows it to scale very well. * it allows you to invalidate all existing authentication cookies for users by updating the secret. Normally a session cookie is used to track sessions; that means that as long as a user keeps his browser open (and does not explicitly log out) the session remains opens. This can be changed by setting the ``cookie_lifetime`` property of the plugin to the number of seconds the cookie should remain valid *after the moment of login*. Using plone.session ------------------- plone.session only takes care of handling sessions for already authenticated users. This means it can not be used stand-alone: you need to have another PAS plugin, such as the standard *Cookie Auth Helper* to take care of authentication. After a user has been authenticated plone.session can take over via the PAS *credentials update* mechanism. Using custom session authentication ----------------------------------- plone.session delegates the generation and verification of sessions to an ISessionSource adapter. This adapter adapts the PAS plugin and implements four methods: createIdentifier Return an identifier for a userid. An identifier is a standard python string object. verifyIdentifier Verify if an identity corresponds to a valid session. Returns a boolean indicating if the identify is valid. extractLoginName Extract the login name from an identifier. invalidateSession Mark a session for a principal as invalid. A source may not support this, in which case it should return False. plone.session ships with two example adapers: hash and userid. The userid adapter is a trivial example which uses the userid as session identifier. This is very insecure since there is no form of verification at all. DO NOT USE THIS ADAPTER IN YOUR SITE! The hash plugin creates a random secret string which is stored as an attribute on your plugin. It uses this secret to create a SHA1 signature for the user id with the secret as session identifier. This approach has several good qualities: * it allows us to verify that a session identifier was created by this site * there is no need to include passwords in the session idenfitier * it does not need to store anything in Zope itself. This means it works as-is in ZEO setups and can scale very well. There are a few downsides to this approach: * if a users password is changed or disabled session identifiers will continue to work, making it hard to lock out users

plone.versioncheck-1.2.1-1.lbn25.py37.noarch

Checks pinned versions with overrides in a cascaded buildout