Search results

plone.app.workflow-2.2.7-1.lbn25.noarch

============ plone.app.workflow contains workflow- and security-related features for Plone, including the sharing view.

plone.app.workflowmanager-2.0b1-1.lbn25.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.z3cform-1.2.0-3.lbn25.noarch

A collection of widgets, templates and other components for use with z3c.form and Plone

plone.autoform-1.7.0-2.lbn25.noarch

plone.autoform builds custom z3c.form forms based on a model (schema) of what fields to include and what widgets and options should be used for each field. This model is defined as a zope.schema-based schema, but additional hints can be supplied to control aspects of form display not normally specified in a Zope schema. Basic schema-based forms To use the automatic form setup, mix in the following base class in your forms: >>> from plone.autoform.form import AutoExtensibleForm and then provide the schema (a schema interface) and optionally the additionalSchemata (a list of schema interfaces) attributes on your form: class MyForm(AutoExtensibleForm, form.EditForm): schema = IMySchema additionalSchemata = (ISchemaOne, ISchemaTwo,) For dynamic forms, you could of course make schema and additionalSchemata into properties. For example, plone.dexterity extends the basic AutoExtensibleForm so that schema is the content type schema and additionalSchemata is a list of field provider schemas associated with behaviors. Controlling form presentation Directives can be specified in the schema to control aspects of form presentation. Changing a field's display mode A field's widget can be displayed in several "modes": input - allows the user to enter data into the field display - a read-only indication of the field's value hidden - a record of the field's value that is included only in the HTML source The mode can be controlled using the mode directive: from plone.supermodel import model from plone.autoform import directives as form class IMySchema(model.Schema): form.mode(secret='hidden') form.mode(IEditForm, secret='input') secret = schema.TextLine( title=u"Secret", default=u"Secret stuff (except on edit forms)" ) In this case the mode for the secret field is set to 'hidden' for most forms, but 'input' for forms that provide the IEditForm interface. The corresponding supermodel XML directive is form:mode: <field type="zope.schema.TextLine" name="secret" form:mode="z3c.form.interfaces.IForm:hidden z3c.form.interfaces.IEditForm:input"> <title>Secret</title> <description>Secret stuff (except on edit forms)</description> </field> The mode can be specified briefly if it should be the same for all forms: <field type="zope.schema.TextLine" name="secret" form:mode="hidden"> <title>Secret</title> <description>Secret stuff</description> </field> In other words, form:mode may be either a single mode, or a space-separated list of form_interface:mode pairs. Omitting fields A field can be omitted entirely from all forms, or from some forms, using the omitted and no_omit diretives. In this example, the dummy field is omitted from all forms, and the edit_only field is omitted from all forms except those that provide the IEditForm interface: from z3c.form.interfaces import IEditForm from plone.supermodel import model from plone.autoform import directives as form class IMySchema(model.Schema): form.omitted('dummy') dummy = schema.Text( title=u"Dummy" ) form.omitted('edit_only') form.no_omit(IEditForm, 'edit_only') edit_only = schema.TextLine( title = u'Only included on edit forms', ) In supermodel XML, this can be specified as: <field type="zope.schema.TextLine" name="dummy" form:omitted="true"> <title>Dummy</title> </field> <field type="zope.schema.TextLine" name="edit-only" form:omitted="z3c.form.interfaces.IForm:true z3c.form.interfaces.IEditForm:false"> <title>Only included on edit form</title> </field> form:omitted may be either a single boolean value, or a space-separated list of form_interface:boolean pairs. Re-ordering fields A field's position in the form can be influenced using the order_before and order_after directives. In this example, the not_last field is placed before the summary field even though it is defined afterward: from plone.supermodel import model from plone.autoform import directives as form class IMySchema(model.Schema): summary = schema.Text( title=u"Summary", description=u"Summary of the body", readonly=True ) form.order_before(not_last='summary') not_last = schema.TextLine( title=u"Not last", ) The value passed to the directive may be either '*' (indicating before or after all fields) or the name of another field. Use '.fieldname' to refer to field in the current schema or a base schema. Prefix with the schema name (e.g. 'IDublinCore.title') to refer to a field in another schema. Use an unprefixed name to refer to a field in the current or the default schema for the form. In supermodel XML, the directives are called form:before and form:after. For example: <field type="zope.schema.TextLine" name="not_last" form:before="*"> <title>Not last</title> </field> Organizing fields into fieldsets Fields can be grouped into fieldsets, which will be rendered within an HTML <fieldset> tag. In this example the footer and dummy fields are placed within the extra fieldset: from plone.supermodel import model from plone.autoform import directives as form class IMySchema(model.Schema): model.fieldset('extra', label=u"Extra info", fields=['footer', 'dummy'] ) footer = schema.Text( title=u"Footer text", ) dummy = schema.Text( title=u"Dummy" ) In supermodel XML fieldsets are specified by grouping fields within a <fieldset> tag: <fieldset name="extra" label="Extra info"> <field name="footer" type="zope.schema.TextLine"> <title>Footer text</title> </field> <field name="dummy" type="zope.schema.TextLine"> <title>Dummy</title> </field> </fieldset> Changing a field's widget Usually, z3c.form picks a widget based on the type of your field. You can change the widget using the widget directive if you want users to enter or view data in a different format. For example, here we change the widget for the human field to use yes/no radio buttons instead of a checkbox: from plone.supermodel import model from plone.autoform import directives as form from z3c.form.browser.radio import RadioFieldWidget class IMySchema(model.Schema): form.widget('human', RadioFieldWidget) human = schema.Bool( title = u'Are you human?', ) You can also pass widget parameters to control attributes of the widget. For example, here we keep the default widget, but set a CSS class: from plone.supermodel import model from plone.autoform import directives as form from z3c.form.browser.radio import RadioWidget class IMySchema(model.Schema): form.widget('human', klass='annoying') human = schema.Bool( title = u'Are you human?', ) In supermodel XML the widget is specified using a <form:widget> tag, which can have its own elements specifying parameters: <field name="human" type="zope.schema.TextLine"> <title>Are you human?</title> <form:widget type="z3c.form.browser.radio.RadioWidget"> <klass>annoying</klass> </form:widget> </field> Note: In order to be included in the XML representation of a schema, widget parameters must be handled by a WidgetExportImportHandler utility. There is a default one which handles the attributes defined in z3c.form.browser.interfaces.IHTMLFormElement. Protect a field with a permission By default, fields are included in the form regardless of the user's permissions. Fields can be protected using the read_permission and write_permission directives. The read permission is checked when the field is in display mode, and the write permission is checked when the field is in input mode. The permission should be given with its Zope 3-style name (i.e. cmf.ManagePortal rather than 'Manage portal'). In this example, the secret field is protected by the cmf.ManagePortal permission as both a read and write permission. This means that in both display and input modes, the field will only be included in the form for users who have that permission: from plone.supermodel import model from plone.autoform import directives as form class IMySchema(model.Schema): form.read_permission(secret='cmf.ManagePortal') form.write_permission(secret='cmf.ManagePortal') secret = schema.TextLine( title = u'Secret', ) In supermodel XML the directives are security:read-permission and security:write-permission: <field type="zope.schema.TextLine" name="secret" security:read-permission="cmf.ManagePortal" security:write-permission="cmf.ManagePortal"> <title>Secret</title> </field> Display Forms Sometimes rather than rendering a form for data entry, you want to display stored values based on the same schema. This can be done using a "display form." The display form renders each field's widget in "display mode," which means that it shows the field value in read-only form rather than as a form input. To use the display form, create a view that extends WidgetsView like this: >>> from plone.autoform.view import WidgetsView >>> class MyView(WidgetsView): ... schema = IMySchema ... additionalSchemata = (ISchemaOne, ISchemaTwo,) ... ... # ... To render the form, do not override __call__(). Instead, either implement the render() method, set an index attribute to a page template or other callable, or use the template attribute of the <browser:page /> ZCML directive when registering the view. In the template, you can use the following variables: view/w is a dictionary of all widgets, including those from non-default fieldsets (by contrast, the widgets variable contains only those widgets in the default fieldset). The keys are the field names, and the values are widget instances. To render a widget (in display mode), you can do tal:replace="structure view/w/myfield/render" />. view/fieldsets is a dictionary of all fieldsets (not including the default fieldset, i.e. those widgets not placed into a fieldset). They keys are the fieldset names, and the values are the fieldset form instances, which in turn have variables like widgets given a list of all widgets. Behind the scenes: how autoform directives work Zope schema fields do not allow storing arbitrary key-value data associated with a particular field. However, arbitrary data can be stored in a dictionary on the schema (interface) known as the "tagged values." This is where plone.autoform keeps track of its extra hints, whether they are configured via Python directives, an XML model, or some other way. The tagged values are stored under various keys, which are defined in the plone.autoform.interfaces module. They can be set several ways: Manually, by using setTaggedValue() on an interface. By loading the schema from a plone.supermodel XML file and using the form: prefix By using the directives from plone.autoform.directives while defining a schema in Python.

plone.batching-1.0.8-1.lbn25.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.behavior-1.3.2-1.lbn25.noarch

This package provides support for behaviors. A behavior is a re-usable aspect of an object that can be enabled or disabled without changing the component registry. A behavior is described by an interface, and has metadata such as a title and a description. The behavior can be looked up by a given short name or by the dotted name of the interface. With this unique name behaviors metadata can be looked up. When the behavior is enabled for an object, you will be able to adapt the object to the interface. In some cases, the interface can be used as a marker interface as well. As an example, let’s say that your application needs to support object-level locking. This can be modeled via an adapter, but you want to leave it until runtime to determine whether locking is enabled for a particular object. You could then register locking as a behavior. Requirements and Limitations: This package comes with support for registering behaviors and factories. It does not implement the policy for determining what behaviors are enabled on a particular object at a particular time. That decision is deferred to an IBehaviorAssignable adapter, which must be implemented (plone.dexterity implements this). Like the IBehaviorAssignable plumbing, marker interface support needs to be enabled on a per-application basis. This package also does not directly support the adding of marker interfaces to instances. To do that, you can either use an event handler to mark an object when it is created, or a dynamic __providedBy__ descriptor that does the lookup on the fly (but you probably want some caching). A sample event handler is provided with this package, but is not registered by default The intention is that behavior assignment is generic across an application, used for multiple, optional behaviors. It probably doesn’t make much sense to use plone.behavior for a single type of object. The means to keep track of which behaviors are enabled for what types of objects will be application specific.

plone.browserlayer-2.2.0-1.lbn25.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.cachepurging-1.0.16-1.lbn25.noarch

The plone.cachepurging package provides cache purging for Zope 2 applications. It is inspired by (and borrows some code from) Products.CMFSquidTool, but it is not tied to Squid. In fact, it is tested mainly with Varnish, though it should also work with Squid and Enfold Proxy. This package is not tied to Plone. However, if you intend to use it with Plone, you probably want to install plone.app.caching, which provides Plone-specific configuration and a user interface in Plone’s control panel. plone.cachepurging works with Zope 2.12 and later. If you want to use it with Zope 2.10, you may be able to do so by installing ZPublisherEventsBackport, although this is not a tested configuration.

plone.caching-1.0.1-1.lbn25.noarch

Zope 2 integration for z3c.caching

plone.contentratings-1.2.1-1.lbn25.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 jquery actions.