Modified items

All recently modified items, latest first.

plone.recipe.alltests-1.5-1.lbn25.noarch: Buildout recipe for running tests isolated at package boundaries

plone.protect-3.0.18-1.lbn25.noarch: This package contains utilities that can help to protect parts of Plone or applications build on top of the Plone framework. protect decorator ================= The most common way to use plone.protect is through the 'protect' decorator. This decorator takes a list of *checkers* as parameters: each checker will check a specific security aspect of the request

plone.formwidget.recurrence-1.2.6-2.lbn25.noarch: The plone.formwidget.recurrence package provides an Archetype and a z3cform widget for recurrence. The main GUI work is done with the jquery.recurrenceinput.js widget from http://github.com/collective/jquery.recurrenceinput.js . This widget also provides a simple textarea where a RFC 5545 compliant recurrence rule can be entered, if javascript is not available. The resulting value of the widget is a RFC5445 compliant recurrence rule string, ready to be used with python-dateutil's rrulestr.

plone.formwidget.querystring-1.1.10-2.lbn25.noarch: This widget is used by the contentlisting tile and the dexterity-based version of plone.app.collection (>2.0), to make selections, and ‘build’ your query. It stores a list of dictionaries containing the query you’ve build. This query is being parsed by using plone.app.collection and that used plone.app.contentlisting to display the results in the tile.

plone.formwidget.namedfile-1.0.15-1.lbn25.noarch: This package provides z3c.form widgets for file and image upload/download, with the option of keeping the existing file or replacing it with a new one. The widgets will act as the default for any NamedFile, NamedBlobFile, NamedImage or NamedBlobImage field from the plone.namedfile package.

plone.formwidget.multifile-1.1-1.lbn25.noarch: plone.formwidget.multifile is a z3c.form-widget which lets users upload multiple files, either at once, or in batches using repeated form submissions. Browsers that do not implement the file input "multiple" attribute are supported via javascript adding of multiple file inputs. This also works with browsers that do support "multiple", and allows users to add and remove files in bundles. Upload does not occur until the form is saved.

plone.formwidget.geolocation-1.4-1.lbn25.noarch: Geolocation field and widget for use with collective.geolocationbehavior This package provides a field and a basic widget allowing text entry of latitude and longitude, which may be extended by other packages to integrate Google Maps or other mapping tools.

plone.formwidget.datetime-1.3.4-1.lbn25.noarch: The package plone.formwidget.datetime provides date and time widgets for plone to be used with z3c.form and Archetypes. The calendar widget is based on JQueryTools Dateinput, provided by plone.app.jquerytools. The package is a merge of collective.z3cform.datetimewidget and archetypes.datetimewidget (which itself was derived from collective.z3cform.datetimewidget).

plone.formwidget.contenttree-1.1.0-1.lbn25.noarch: plone.formwidget.contenttree is a z3c.form widget for use with Plone. It uses the jQuery Autocomplete widget, and has graceful fallback for non- Javascript browsers. There is a single-select version (AutocompleteSelectionFieldWidget) for Choice fields, and a multi-select one (AutocompleteMultiSelectionFieldWidget) for collection fields (e.g. List, Tuple) with a value_type of Choice. When using this widget, the vocabulary/source has to provide the IQuerySource interface from z3c.formwidget.query and have a search() method. The easiest way to do this is generate one with one of: * plone.formwidget.contenttree.PathSourceBinder(navigation_tree_query=None, **kw) * plone.formwidget.contenttree.ObjPathSourceBinder(navigation_tree_query=None, **kw) * plone.formwidget.contenttree.UUIDSourceBinder(navigation_tree_query=None, **kw) Where ``navigation_tree_query`` is some restrictions that should be applied to any Catalog query. The rest of the arguments are used to form a filter (see source.py). ``PathSourceBinder`` and ``ObjPathSourceBinder`` store the selected object's path in the field value. This means that the link will be broken if the object is moved. ``UUIDSourceBinder`` stores UUID references, so will handle pages being moved. If you do not want to filter the content tree whatsoever, there are some pre-baked instances too: * plone.formwidget.contenttree.path_src_binder * plone.formwidget.contenttree.obj_path_src_binder * plone.formwidget.contenttree.uuid_src_binder

plone.formwidget.autocomplete-1.3.0-1.lbn25.noarch: plone.formwidget.autocomplete is a z3c.form widget for use with Plone. It uses the jQuery Autocomplete widget, and has graceful fallback for non- Javascript browsers. There is a single-select version (AutocompleteFieldWidget) for Choice fields, and a multi-select one (AutocompleteMultiFieldWidget) for collection fields (e.g. List, Tuple) with a value_type of Choice. When using this widget, the vocabulary/source has to provide the IQuerySource interface from z3c.formwidget.query and have a search() method.

plone.formwidget-1.0.15-1.lbn25.noarch: plone.formwidget Python module/namespace base

plone.folder-1.0.10-1.lbn25.noarch: BTree-based folder implementation with order support

plone.fieldsets-2.0.3-1.lbn25.noarch: An extension to zope.formlib, which allows to group fields into different fieldsets.

plone.event-1.3.4-1.lbn25.noarch: Event/Calendaring related infrastructure. Recurrence calculation tools based on RFC2445 and timedelta recurrence rules, timezone tools and date conversion tools. Parts of this package derived from Products.DateRecurringIndex.

plone.directives.form-2.0.3-1.lbn25.noarch: Grok-like directives configuring forms

plone.directives.dexterity-1.0.2-3.lbn25.noarch: Grok-like directives for creating Dexterity content

plone.directives-2.0.3-1.lbn25.noarch: plone.directives Python module/namespace base

plone.dexterity-2.4.2-1.lbn25.noarch: Dexterity is a system for building content types, both through-the-web and as filesystem code. It is aimed at Plone, although this package should work with plain Zope + CMF systems. Key use cases Dexterity wants to make some things really easy. These are: * Create a "real" content type entirely through-the-web without having to know programming. * As a business user, create a schema using visual or through-the-web tools, and augment it with adapters, event handlers, and other Python code written on the filesystem by a Python programmer. * Create content types in filesystem code quickly and easily, without losing the ability to customise any aspect of the type and its operation later if required. * Support general "behaviours" that can be enabled on a custom type in a declarative fashion. Behaviours can be things like title-to-id naming, support for locking or versioning, or sets of standard metadata with associated UI elements. * Easily package up and distribute content types defined through-the-web, on the filesystem, or using a combination of the two. Philosophy Dexterity is designed with a specific philosophy in mind. This can be summarised as follows: Reuse over reinvention As far as possible, Dexterity should reuse components and technologies that already exist. More importantly, however, Dexterity should reuse concepts that exist elsewhere. It should be easy to learn Dexterity by analogy, and to work with Dexterity types using familiar APIs and techniques. Small over big Mega-frameworks be damned. Dexterity consists of a number of speciaised packages, each of which is independently tested and reusable. Furthermore, packages should has as few dependencies as possible, and should declare their dependencies explicitly. This helps keep the design clean and the code manageable. Natural interaction over excessive generality The Dexterity design was driven by several use cases (see docs/Design.txt) that express the way in which we want people to work with Dexterity. The end goal is to make it easy to get started, but also easy to progress from an initial prototype to a complex set of types and associated behaviours through step-wise learning and natural interaction patterns. Dexterity aims to consider its users - be they business analysts, light integrators or Python developers, and be they new or experienced - and cater to them explicitly with obvious, well-documented, natural interaction patterns. Real code over generated code Generated code is difficult to understand and difficult to debug when it doesn't work as expected. There is rarely, if ever, any reason to scribble methods or 'exec' strings of Python code. Zope 3 over Zope 2 Although Dexterity does not pretend to work with non-CMF systems, as many components as possible should work with plain Zope 3, and even where there are dependencies on Zope 2, CMF or Plone, they should - as far as is practical - follow Zope 3 techniques and best practices. Many operations (e.g. managing objects in a folder, creating new objects or manipulating objects through a defined schema) are better designed in Zope 3 than they were in Zope 2. Zope concepts over new paradigms We want Dexterity to be "Zope-ish" (and really, "Zope 3-ish"). Zope is a mature, well-designed (well, mostly) and battle tested platform. We do not want to invent brand new paradigms and techniques if we can help it. Automated testing over wishful thinking "Everything" should be covered by automated tests. Dexterity necessarily has a lot of moving parts. Untested moving parts tend to come lose and fall on people's heads. Nobody likes that.

plone.app.themingplugins-1.0-1.lbn25.noarch: plone.app.theming supports plugins that allow theme authors to bundle more advanced functionality with their themes. This package contains two such plugins: The ability to override specific Zope Page Templates when a theme is enabled The ability to register views providing custom markup using Zope Page Templates when a theme is enabled Both of these only work for themes distributed on the filesystem (either in a Python package or in the global themes resource directory), i.e. not for themes imported through-the-web in ZIP archives. That said, the features provided by these plugins are more likely to be useful in building “customer” sites (where filesystem development is likely to be the norma) than in distributing generic themes (where the through-the-web ZIP import is more attractive).

plone.app.registry-1.6.1-1.lbn25.noarch: plone.app.registry provides Plone UI and GenericSetup integration for plone.registry, which in turn implements a configuration registry for Zope applications. For details about how the registry works, please see the plone.registry documentation. What follows is a brief overview of common usage patterns in Plone.

« Previous 20 items Next 20 items » 1 2 3 4 5 6 7 8 ... 1684


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

Sections

Modified items