Modified items

All recently modified items, latest first.

plone.intelligenttext-2.0.2-1.lbn13.noarch

plone.indexer-1.0.2-1.lbn13.noarch: This package provides primitives to help delegate ZCatalog indexing operations to adapters. It doesn't do very much on its own, but can be used by catalog implementations that want to allow individual index values to be provided not by the object itself, but by separate adapters.

plone.i18n-2.0.9-1.lbn13.noarch: Advanced i18n/l10n features useful in a CMS environment.

plone.formwidget.recurrence-1.2.1-1.lbn13.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.namedfile-1.0.7-1.lbn13.noarch: Image widget for z3c.form and Plone

plone.formwidget.contenttree-1.0.7-1.lbn13.noarch: AJAX selection widget for Plone

plone.formwidget.autocomplete-1.2.6-1.lbn13.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.7-1.lbn13.noarch: plone.formwidget Python module/namespace base

plone.folder-1.0.5-1.lbn13.noarch: BTree-based folder implementation with order support

plone.fieldsets-2.0.2-2.lbn13.noarch: An extension to zope.formlib, which allows to group fields into different fieldsets.

plone.event-1.1-1.lbn13.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-1.lbn13.noarch: Grok-like directives configuring forms

plone.directives.dexterity-1.0.2-2.lbn13.noarch: Grok-like directives for creating Dexterity content

plone.directives-2.0-1.lbn13.noarch: plone.directives Python module/namespace base

plone.dexterity-2.2.1-1.lbn13.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.contentrules-2.0.4-1.lbn13.noarch: plone.contentrules provides a "pure Zope 3" implementation of a rules engine which allows arbitary conditions and actions to be combined into rules, and rules to be executed dependent on events. You can think of this as somewhat similar to user-assembled mail filtering rules or something like Apple's Automator. It is used by plone.app.contentrules to provide such functionality for Plone.

plone.contentratings-1.0.1_2-1.lbn13.noarch: plone.contentratings is an add-on package for the Plone content management system. It extends the Zope3 package contentratings to provide through the web configurable rating categories for all CMF content. It AJAX-ifies the rating UI using KSS actions.

plone.caching-1.0-3.lbn13.noarch: Zope 2 integration for z3c.caching

plone.cachepurging-1.0.5-1.lbn13.noarch: Cache purging support for Zope 2 applications

plone.browserlayer-2.1.2-2.lbn13.noarch: This package aims to make it easier to register visual components (e.g. views and viewlets) so that they only show up in a Plone site where they have been explicitly installed.

« Previous 20 items Next 20 items » 1 ... 2368 2369 2370 2371 2372 2373 2374 ... 2425


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

Sections

Modified items