Search results

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.

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.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.directives-2.0.3-1.lbn25.noarch

plone.directives Python module/namespace base

plone.directives.dexterity-1.0.2-3.lbn25.noarch

Grok-like directives for creating Dexterity content

plone.directives.form-2.0.3-1.lbn25.noarch

Grok-like directives configuring forms

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.fieldsets-2.0.3-1.lbn25.noarch

An extension to zope.formlib, which allows to group fields into different fieldsets.

plone.folder-1.0.12-1.lbn25.noarch

BTree-based folder implementation with order support

plone.formwidget-1.0.15-2.lbn25.noarch

plone.formwidget Python module/namespace base