Search results for dexterity

python2-plone-directives-dexterity-1.0.2-4.lbn36.noarch

plone.directives.dexterity This package provides optional, Grok-like directives for configuring Dexterity content. It depends on five.grok, which in turn depends on the various re-usable grokcore.* packages, but not Grok itself.See also plone.directives.form, which provides directives for configuring schema interfaces with form hints.Content classes Content extending the Dexterity 'Item' and...

python2-plone-directives-dexterity-1.0.2-4.lbn36.noarch

plone.directives.dexterity This package provides optional, Grok-like directives for configuring Dexterity content. It depends on five.grok, which in turn depends on the various re-usable grokcore.* packages, but not Grok itself.See also plone.directives.form, which provides directives for configuring schema interfaces with form hints.Content classes Content extending the Dexterity 'Item' and...

python2-products-cmfdifftool-3.3.3-1.lbn36.noarch

Diff tool for Plone.Dexterity To enable versioning for a Dexterity content type you need to:1. Install plone.app.versioningbehavior_ and use it on your content type. 2. Enable versioning for the type in the types control panel. 3. Install this package. 4. Go to the portal_diff tool ZMI page. 5. Add Compound Diff for Dexterity types for your content type. Field name can be anything, e.g:...

python2-transmogrify-dexterity-2.0.0-1.lbn36.noarch

Introduction The transmogrify.dexterity package provides a transmogrifier pipeline section for updating field values of dexterity content objects. The blueprint name is transmogrify.dexterity.schemaupdater.The schemaupdater section needs at least the path to the object to update. Paths to objects are always interpreted as being relative to the context. Any writable field who's id matches a key...

lineage.index-0.4-1.lbn19.noarch

lineage.index is an addon to collective.lineage that lets you search for content within a certain childsite. How does it work? lineage.index registers an index childsite on all items implementing Products.CMFCore.interfaces.IContentish (which will be all Archetypes and Dexterity based content types). The childsite's id can be used to search for content located in this childsite. When listing items on the main portal, you can use the metadata-column childsite to indicate which childsites the content has been aggregated from. Gotchas The vocabulary caches all childsite titles until zope is restarted. If you add childsites you need to restart zope to make them show up in the vocabulary.

plone.app.contenttypes-1.1.9-1.lbn19.noarch

Introduction plone.app.contenttypes offers default content types for Plone based on Dexterity. This package replaces Products.ATContenttypes and will provide the default-types in Plone 5. It contains the following types: Folder Document News item File Image Link Event (Using behaviors from plone.app.event) Collection (this already replaces plone.app.collection which is no longer needed then) The main difference from a users perspective is that these types are extendable through-the-web. This means you can add or remove fields and behaviors using the control-panel "Dexterity Content Types" (/@@dexterity-types). The aim is to mimick the default-types as closely as possible. plone.app.contenttypes has been merged into the Plone 5.0 branch and will be shipped with the next Plone release: https://dev.plone.org/ticket/12344 Warning: Using plone.app.contenttypes on a site with existing content requires migrating the sites content. Please see the chapter "Migration". It can be used on a new site without problems. Compatibility Version 1.1b1 is tested with Plone 4.3.x. The versions 1.1.x will stay compatible with Plone 4.3.x. For support of Plone 4.1 and 4.2 please use version 1.0.x. Please note that they do not provide the full functionality. The future versions 1.2.x will be compatible with Plone 5 only and add support for plone.app.widgets Installation Add this line in the eggs section of your buildout.cfg eggs = ... plone.app.contenttypes If you have a Plone site with mixed Archetypes and Dexterity content use the extra requirement atrefs. eggs = ... plone.app.contenttypes [atrefs] This will also install the package plone.app.referenceablebehavior that allows you to reference dexterity-based content from archetypes-based content. You will have to enable the behavior plone.app.referenceablebehavior.referenceable.IReferenceable for all types that need to be referenced by Archetypes-content. What happens to existing content? If you install plone.app.contenttypes in a existing site all Archetypes-based content of the default types still exists and can be viewed but can't be edited. On installation plone.app.contenttypes removes the type-definitions for the old default-types like this: <object name="Document" remove="True" /> They are then replaced by new Definitions: <object meta_type="Dexterity FTI" name="Document" /> To make the existing content editable again you need to migrate it to Dexterity (please see the section on migration) or uninstall plone.app.contenttypes (see the section on uninstalling). Archetypes-based content provided by add-ons (e.g. Products.PloneFormGen) will still work since only the default-types are replaced. If you install plone.app.contenttypes on a fresh site (i.e. when no content has been edited or added) the usual default-content (Events, News, Members...) will be created as dexterity-content. Uninstalling To remove plone.app.contenttypes and return full functionality to old content and restore the AT-based default-types you have to install the import step "Types Tool" of the current base profile. Follow the following steps: in the ZMI navigate to portal_setup and the tab "import" in "Select Profile or Snapshot" leave "Current base profile (<Name of your Plonesite>)" selected. This is usually Products.CMFPlone select the Types Tool (usually Step 44) click "import selected steps" Any content you created based on plone.app.contenttypes will not be editable until you reinstall plone.app.contenttypes. Dependencies plone.app.dexterity >= 2.0.7. Dexterity is shipped with Plone 4.3.x. Version pinns for Dexterity are included in Plone 4.2.x. For Plone 4.1.x you need to pin the correct version for Dexterity in your buildout. See Installing Dexterity on older versions of Plone. plone.dexterity >= 2.2.1. Olders version of plone.dexterity break the rss-views because plone.app.contenttypes uses behaviors for the richtext-fields. plone.app.event >= 1.1b1. This provides the behaviors used for the event-type. plone.app.portlets >= 2.5a1. In older version the event-portlet will not work with the new event-type. These are the version-pinns for Plone 4.3.3: [buildout] versions = versions [versions] plone.app.event = 1.1b1 plone.app.portlets = 2.5a1 Plone-versions before 4.3.3 need to pinn more packages: [buildout] versions = versions [versions] plone.dexterity = 2.2.1 plone.app.dexterity = 2.0.11 plone.schemaeditor = 1.3.5 plone.app.event = 1.1b1 plone.app.portlets = 2.5a1 Migration To migrate your existing content from Archetypes to Dexterity use the form at /@@atct_migrator. For migrations to work you need at least Products.contentmigration = 2.1.3 (part of Plone since Plone 4.2.5) and plone.app.intid (part of Plone since Plone 4.1.0). Migrating Archetypes-based content to plone.app.contenttypes plone.app.contenttypes can migrate the following default types: Document Event File Folder Image Link News Item Collection The following non-default types will also be migrated: The AT-based Event-type provided by plone.app.event The DX-based Event-type provided by plone.app.event The Event-type provided by plone.app.contenttypes until version 1.0 News Items with blobs (provoded by https://github.com/plone/plone.app.blob/pull/2) Files and Images without blobs AT-based collection provided by plone.app.collection Migrations that might come in a future version: from ATTopic to Collections Please note that migrating versions of content is not supported. Only the current state of items is migrated without any content- or workflow-history. Migrating content that is translated with LinguaPlone Since LinguaPlone does not support Dexterity you need to migrate from LinguaPlone to plone.app.multilingual (http://pypi.python.org/pypi/plone.app.multilingual). The migration from Products.LinguaPlone to plone.app.multilingual should happen before the migration from Archetypes to plone.app.contenttypes. For details on the migration see http://pypi.python.org/pypi/plone.app.multilingual#linguaplone-migration Migrating from old versions of plone.app.contenttypes Before version 1.0a2 the content-items did not implement marker-interfaces. They will break in newer versions since the views are now registered for these interfaces (e.g. plone.app.contenttypes.interfaces.IDocument). To fix this you can call the view /@@fix_base_classes on your site-root. Since plone.app.contenttypes 1.1a1, the Collection type uses the new Collection behavior and the Event type utilizes behaviors from plone.app.event. In order to upgrade: First run the default profile (plone.app.contenttypes:default) or reinstall plone.app.contenttypes Then run the upgrade steps. Migrating default-content that was extended with archetypes.schemaextender The migration should warn you if any of your types are extended with archetypes.schemaextender. The data contained in these fields will be lost. You need to implement a custom migration for your types and dexterity-behaviors for the functionality provided by the schemaextenders. This is an advanced development task and beyond the scope of this documentation. Migrating custom content Custom content-types will not be touched by the migration plone.app.contenttypes and will continue to work as expeced. However if you'd like to migrate your content-types to Dexterity (you'll have to create these types in Dexterity first) you might want to have a look at the code of plone.app.contenttypes.migration.migration.NewsItemMigrator as a blueprint. Widgets When used in Plone 4.x plone.app.contenttypes uses the default z3c.form widgets. All widgets work as they used to with Archetypes except for the keywords-widget for which a simple linesfield is used. It is recommended to use plone.app.widgets to switch to the widgets that will be used in Plone 5. How to use with plone.app.widgets TODO How to override widgets To override the default keywords-widgets with a nicer widget you can use the package collective.z3cform.widgets. Add collective.z3cform.widgets to your buildout and in your own package register the override in your configure.zcml: <adapter factory=".subjects.SubjectsFieldWidget" /> Then add a file subjects.py from collective.z3cform.widgets.token_input_widget import TokenInputFieldWidget from plone.app.dexterity.behaviors.metadata import ICategorization from plone.app.z3cform.interfaces import IPloneFormLayer from z3c.form.interfaces import IFieldWidget from z3c.form.util import getSpecification from z3c.form.widget import FieldWidget from zope.component import adapter from zope.interface import implementer @adapter(getSpecification(ICategorization['subjects']), IPloneFormLayer) @implementer(IFieldWidget) def SubjectsFieldWidget(field, request): widget = FieldWidget(field, TokenInputFieldWidget(field, request)) return widget Once you install collective.z3cform.widgets in the quickinstaller, the new widget will then be used for all types. Information for Addon-Developers Design decicions The schemata for the types File, Image and Link are defined in xml-files using plone.supermodel. This allows the types to be editable trough the web. The types Document, News Item, Folder and Event have no schemata but only use behaviors to provide their fields. Installation as a dependency from another product If you want to add plone.app.contenttypes as a dependency from another products use the profile plone-content in your metadata.xml to have Plone populate a new site with DX-based default-content. <metadata> <version>1</version> <dependencies> <dependency>profile-plone.app.contenttypes:plone-content</dependency> </dependencies> </metadata> If you use the profile default then the default-content in new sites will still be Archetypes-based. You'll then have to migrate that content using the migration-form @@atct_migrator or delete it by hand. Extending the types You have several options: Extend the types through-the-web by adding new fields or behaviors in the types-controlpanel /@@dexterity-types. Extend the types with a custom type-profile that extends the existing profile with behaviors, or fields. You will first have to add the type to your [yourpackage]/profiles/default/types.xml. <?xml version="1.0"?> <object name="portal_types" meta_type="Plone Types Tool"> <object name="Folder" meta_type="Dexterity FTI" /> </object> Here is an example that enables the image-behavior for Folders in [yourpackage]/profiles/default/types/Folder.xml: <?xml version="1.0"?> <object name="Folder" meta_type="Dexterity FTI"> <property name="behaviors" purge="False"> <element value="plone.app.contenttypes.behaviors.leadimage.ILeadImage"/> </property> </object> By adding a schema-definition to the profile you can add fields. <?xml version="1.0"?> <object name="Folder" meta_type="Dexterity FTI"> <property name="model_file">your.package.content:folder.xml</property> <property name="behaviors" purge="False"> <element value="plone.app.contenttypes.behaviors.leadimage.ILeadImage"/> </property> </object> Put the schema-xml in your/package/content/folder.xml (the folder content needs a __init__.py) <model xmlns:security="http://namespaces.plone.org/supermodel/security" xmlns:marshal="http://namespaces.plone.org/supermodel/marshal" xmlns:form="http://namespaces.plone.org/supermodel/form" xmlns="http://namespaces.plone.org/supermodel/schema"> <schema> <field name="teaser_title" type="zope.schema.TextLine"> <description/> <required>False</required> <title>Teaser title</title> </field> <field name="teaser_subtitle" type="zope.schema.Text"> <description/> <required>False</required> <title>Teaser subtitle</title> </field> <field name="teaser_details" type="plone.app.textfield.RichText"> <description/> <required>False</required> <title>Teaser details</title> </field> </schema> </model> For more complex features you should create custom behaviors and/or write your own content-types. For more information on creating custom dexterity-types or custom behaviors to extend these types with read the dexterity documentation. Reordering fields provided by behaviors TODO Differences to Products.ATContentTypes The image of the News Item is not a field on the contenttype but a behavior that can add a image to any contenttypes (similar to http://pypi.python.org/pypi/collective.contentleadimage) All richtext-fields are also provided by a reuseable behavior. The functionality to transform (rotate and flip) images has been removed. There is no more field Location. If you need georeferenceable consider using collective.geo.behaviour The link on the image of the newsitem triggers an overlay The link-type now allows the of the variables ${navigation_root_url} and ${portal_url} to construct relative urls. The keywords-widget is not implemented and is replaced by a simple lines-widget unless you override it or use plone.app.widgets. Please see the section on widgets. Toubleshooting Please report issues in the bugtracker at https://github.com/plone/plone.app.contenttypes/issues. ValueError on installing When you try to install plone.app.contenttypes < 1.1a1 in a existing site you might get the following error: (...) Module Products.GenericSetup.utils, line 509, in _importBody Module Products.CMFCore.exportimport.typeinfo, line 60, in _importNode Module Products.GenericSetup.utils, line 730, in _initProperties ValueError: undefined property 'schema' Before installing plone.app.contenttypes you have to reinstall plone.app.collection to update collections to the version that uses Dexterity.

plone.app.dexterity-2.3.6-3.lbn19.noarch

Dexterity is a content type framework for CMF applications, with particular emphasis on Plone. It can be viewed as an alternative to Archetypes that is more light-weight and modular.

plone.app.event-1.2.7-1.lbn19.noarch

Plone.app.event is the calendaring framework for Plone. It provides Dexterity behaviors and an Archetypes type, Timezone support, RFC5545 icalendar export, Recurrence support, event views and a lot more. For a Dexterity event type using plone.app.event, use plone.app.contenttypes 1.1 or newer.

plone.app.lockingbehavior-1.0.7-1.lbn19.noarch

Locking integration for dexterity content objects.

plone.app.multilingual-3.0.2-1.lbn19.noarch

Introduction ============ Talking about multi-language support in Plone is talk about Products.LinguaPlone. It has been the *defacto* standard for managing translations of Archetypes-based content types in Plone through the years. Somehow its functionality never made its way into the Plone core and today it is in legacy status. Nowadays, Plone faces the rising of Dexterity content types and its incoming adoption into the Plone core in the near future (4.3) and complete the transition to Plone as default content types in Plone 5. plone.app.multilingual was designed originally to provide Plone a whole multilingual story. Using ZCA technologies, enables translations to Dexterity and Archetypes content types as well managed via an unified UI. This module provides the user interface for managing content translations. It's the app package of the next generation Plone multilingual engine. It's designed to work with Dexterity content types and the *old fashioned* Archetypes based content types as well. It only works with Plone 4.1 and above due to the use of UUIDs for referencing the translations. After more than 7 years, a GSOC, redesigns, reimplementations due to deprecated libraries, two major Plone versions finally we are able to say that plone.app.multilingual is finally here. Components ========== PAM is composed of four packages, two are mandatory: * plone.app.multilingual (UI) * plone.multilingual (core) and two optionals (at least one should be installed): * plone.multilingualbehavior (enables Dexterity support via a behavior) * archetypes.multilingual (enables Archetypes support) Usage ===== To use this package with both Dexterity and Archetypes based content types you should add the following line to your *eggs* buildout section:: eggs = plone.app.multilingual[archetypes, dexterity] If you need to use this package only with Archetypes based content types you only need the following line:: eggs = plone.app.multilingual[archetypes] While archetypes is default in Plone for now, you can strip ``[archetypes]``. This may change in future so we recommend adding an appendix as shown above. Setup ===== After re-running your buildout and installing the newly available add-ons, you should go to the *Languages* section of your site's control panel and select at least two or more languages for your site. You will now be able to create translations of Plone's default content types, or to link existing content as translations. Features ======== These are the most important features PAM provides. Root Language folders --------------------- After the setup, PAM will create root folders for each of your site's languages and put translated content into the appropriate folders. A language folder implements INavigationRoot, so from the user's point of view, each language is "jailed" inside its correspondent language folder. There are event subscribers in place to capture user interaction with content and update the language in contents accordingly, for example when user moves or copy content between language folders. Babel view ---------- An evolution of the LP *translate* view, unified for either Archetypes and Dexterity content types. It features an already translated content viewer for the current content being edited via an ajaxified dinamic selector that shows them on the fly on user request. Language independent fields --------------------------- PAM has support for language independent fields, but with a twist respect the LP implementation. As PAM does design does not give more relevance to one translated object above the others siblings (has no canonical object), fields marked as language independent get copied over all the members of the translation group always. The PAM UI will warn you about this behavior by reminding you that the values in the field on the other group participants will be overwritten. Translation locator policy -------------------------- When translating content, this policy decides how it would be placed in the site's structure. There are two policies in place: * LP way, the translation gets placed in the nearest translated folder in parent's hierarchy * Ask user where to place the translated element in the destination language root folder Language selector policy ------------------------ While browsing the site, the language selector viewlet allows users to switch site's content language and ease access between translations of the current content. There are two policies in place in case the translation of a specific language does not exist (yet): * LP way, the selector shows the nearest translated container. * Shows the user an informative view that shows the current available translations for the current content. Neutral root folder support --------------------------- The root language folders are used to place the tree of the correspondent language content. However, there are some use cases we need content that does not belongs to any language. For example, for assets or side resources like images, videos and documents. There is need to maintain a language neutral folder for place this kind of objects. After PAM setup, there is a special folder called *Language shared*. All items placed in this folder will have neutral as its default language and will be visible from the other root language folders as they were placed there. Translation map --------------- In order to ease the translation tasks, we devised a tool that displays in a useful way all the current translated objects and its current translation information. The map also shows a list of missing translations in case you want to build a *mirrored* (completely) translated site. Google Translation Service integration -------------------------------------- If you are subscriber of the Google Translation service (a paid service), you can setup your API key on *Languages* site setup. Then, you will notice a new icon in the babel view that takes the original field on the left side and using Google Translations service, translates its contents and fill the right side field. LinguaPlone migration --------------------- You can migrate your existing LP powered sites to PAM using the *Migration* tab in the *Languages* control panel. The migration has been divided into 4 steps for separation of concerns and for improving the success of each of the required procedures. Step 0 (optional) - Reindex the language index ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The migration of LinguaPlone content depends on an up-to-date Language index. Use this step to refresh this index. **Warning:** Depending on the number of items in your site, this can take a considerable amount of time. This step is not destructive and can be executed as many times as needed. Step 1 - Relocate content to the proper root language folder ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This step will move the site's content to its correspondent root language folder and previously will make a search for misplaced content through the site's content tree and will move them to its nearest translated parent. **Warning:** This step is destructive as it will alter your content tree structure. Make sure you have previously configured your site's languages properly in the 'Site Languages' tab of the 'Languages' control panel. It's advisable that you do not perform this step on production servers having not tried it in development/preproduction servers previously. Depending on the distribution of your site's content and the accuracy of the language information on each content object you may need to relocate manually some misplaced content after this step. Despite the fact that this step is 'destructive' it can be executed as times as needed if some problem is detected and afterwards you fix the problem. Please, refer to the procedure log when it finishes. Step 2 - Transfer multilingual catalog information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This step will transfer the relations between translations stored by LinguaPlone to the PAM catalog. This step is not destructive and can be executed as many times as needed. Step 3 - Cleanup after migration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This step will search and fix some lost dependencies to the ITranslatable interface hidden in the relation catalog and it gets rid of them. It must be run only when LinguaPlone is already uninstalled, so this step is hidden until then. Marking objects as translatables ================================ Archetypes ---------- By default, if PAM is installed, Archetypes-based content types are marked as translatables Dexterity --------- Users should mark a dexterity content type as translatable by assigning a the multilingual behavior to the definition of the content type either via file system, supermodel or through the web. Marking fields as language independant ====================================== Archetypes ---------- The language independent fields on Archetype-based content are marked the same way as in LinguaPlone:: atapi.StringField( 'myField', widget=atapi.StringWidget( .... ), languageIndependent=True ), .. note:: If you want to completely remove LinguaPlone of your installation, you should make sure that your code are dependant in any way of LP. Dexterity --------- There are four ways of achieve it. Grok directive ~~~~~~~~~~~~~~ In your content type class declaration:: from plone.multilingualbehavior import directives directives.languageindependent('field') Supermodel ~~~~~~~~~~ In your content type XML file declaration:: <field name="myField" type="zope.schema.TextLine" lingua:independent="true"> <description /> <title>myField</title> </field> Native ~~~~~~ In your code:: from plone.multilingualbehavior.interfaces import ILanguageIndependentField alsoProvides(ISchema['myField'], ILanguageIndependentField) Through the web ~~~~~~~~~~~~~~~ Via the content type definition in the *Dexterity Content Types* control panel. Internal design of plone.multilingual ====================================== All the internal features are implemented on the package plone.multilingual. The key points are: 1. Each translation is a content object 2. There is no canonical object 3. The translation reference storage is external to the content object 4. Adapt all the steps on translation 5. Language get/set via an unified adapter 6. Translatable marker interface(s) There is no canonical content object ------------------------------------ Having a canonical object on the content space produces a dependency which is not orthogonal with the normal behavior of Plone. Content objects should be autonomous and you should be able to remove it. This is the reason because we removed the canonical content object. There is a canonical object on the translation infrastructure but is not on the content space. Translation reference storage ----------------------------- In order to maintain the relations between the different language objects we designed a common object called a *translation group*. This translation group has an UUID on its own and each object member of the group stores it in the object catalog register. You can use the ITranslationManager utility to access and manipulate the members of a translation group given one object of the group. Adapt all the steps on translation ---------------------------------- The different aspects involved on a translation are adapted, so it's possible to create different policies for different types, sites, etc. * ITranslationFactory - General factory used to create a new content * ITranslationLocator - Where we are going to locate the new translated content Default : If the parent folder is translated create the content on the translated parent folder, otherwise create on the parent folder. * ITranslationCloner - Method to clone the original object to the new one Default : Nothing * ITranslationIdChooser - Which id is the translation Default : The original id + lang code-block * ILanguageIndependentFieldsManager - Manager for language independent fields Default: Nothing Language get/set via an unified adapter --------------------------------------- In order to access and modify the language of a content type regardless the type (Archetypes/Dexterity) there is a interface/adapter:: plone.multilingual.interfaces.ILanguage You can use:: from plone.multilingual.interfaces import ILanguage language = ILanguage(context).get_language() or in case you want to set the language of a content:: language = ILanguage(context).set_language('ca') Translatable marker interface ----------------------------- In order to know if a content can be translated there is a marker interface: plone.multilingual.interfaces.ITranslatable