Modified items

All recently modified items, latest first.

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.

plone.behavior-1.0.2-1.lbn13.noarch: Infrastructure for maintaining a registry of available behaviors

plone.batching-1.0.1-1.lbn13.noarch: This package includes facilities for creating a batched sequence. It originated from the the PloneBatch module written for Plone which in itself has been based on Zope2's ZTUtils.Batch.

plone.autoform-1.5-1.lbn13.noarch: plone.autoform

plone.app.z3cform-0.7.6-1.lbn13.noarch: A collection of widgets, templates and other components for use with z3c.form and Plone

plone.app.workflowmanager-1.0a4-2.lbn13.noarch: This package provides a GUI for managing custom workflows in Plone. This is the successor of uwosh.northstar's workflow design tool (North* continues on as a file system product generator, given either a PloneFormGen or Dexterity prototype). Features * add/edit/delete new workflows * add content rule actions easily for a workflow transition * graph workflows * easily manipulate workflow permissions Graphing The package also supports graphing workflows. The inspiration for this piece was pretty much taken from DCWorkflowGraph. In order to enable this feature, you'll need to install the Graphviz library. Information can be found at http://www.graphviz.orga workflow manager for plone

plone.app.workflow-2.1.7-1.lbn13.noarch: ============ plone.app.workflow contains workflow- and security-related features for Plone, including the sharing view.

plone.app.vocabularies-2.1.13-1.lbn13.noarch: Overview ======== A collection of generally useful vocabularies for usage in zope.formlib.

plone.app.viewletmanager-2.0.4-1.lbn13.noarch: This component expects you to register storage.ViewletSettingsStorage as a local utility providing IViewletSettingsStorage (CMFPlone does this). The viewlet manager in manager.OrderedViewletManager can then get the filter and order settings. These settings can be configured by 3rd party products and TTW to customize the viewlets per skin.

plone.app.versioningbehavior-1.1-3.lbn13.noarch: The IVersionable behavior is used for enabling the CMFEditions functionality for dexterity contents. It adds a changeNote-field to the edit- and add-forms and creates a new version when the content is edited, if enabled for the content type. It's based on Products.CMFEditions. For listing the versions of an object use CMFEdtions' view versions_history_form or the history viewlet (see default @@view).

« Previous 20 items Next 20 items » 1 ... 2303 2304 2305 2306 2307 2308 2309 ... 2359


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

Sections

Modified items