Search results for dexterity

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

plone.app.referenceablebehavior-0.7.8-1.lbn19.noarch

The “IReferenceable” behavior is used for enabling UUID (plone.app.uuid) support for dexterity contents, like in archetypes content types. This allow for example references between archetypes and dexterity content types. Note: It can’t work with Plone==4.0 because it is based on plone.uuid integration in CMF. It is compatible with Plone>=4.1

plone.app.stagingbehavior-0.1-4.lbn19.noarch

The IStagingSupport behavior is used for enabling the plone.app.iterate functionality for Dexterity content. It allows you to perform the checkout and checkin operations to work on a copy of your original content.

plone.app.versioningbehavior-1.2.10-1.lbn25.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).

plone.app.widgets-1.9.1-1.lbn25.noarch

The goal of plone.app.widgets is to provide an implementation for a new set of javascript widgets being developed in the Plone Mockup project. It overrides existing widgets used in dexterity and archetypes to provide tested and modularized widgets based on the concept of patterns. The widgets that are provided currently are: Adjust Text Size -- Easily change text size on a page. Cookie Directive -- A pattern that checks cookies enabled and asks permission for the user to allow cookies or not. Expose -- Exposes the focused element by darkening everything else on the page. Useful to focus the user attention on a particular area. Form Unload Alert -- A pattern to warn user when changes are unsaved and they try to navigate away from page. Live Search -- Dynamically query the server and display results. Modal -- Creates a modal dialog (also called overlay). Pick A Date -- Allows the user to select a date (with or without time) through a calendar. Picture -- A responsive image widget. Prevent Double Submit -- A pattern to prevent submitting a form twice. Query String for Collections -- A widget for creating query's for collections Related Items -- An advanced widget for selecting related items. Select2 -- Autocompletes, multiple or single selections from any kind of data source (with search!). Table Sorter -- A pattern you can apply to a table so it can have its items rearranged when clicking the header. TinyMCE (v4!!!) -- Rich text editor. Table of Contents -- Automatically generate a table of contents. Tooltip -- A pattern to show a tooltip on hover. DropZone -- Drag 'n drop file upload Widgets that are overridden in Edit forms are: subject language effectiveDate expirationDate contributrors creators relatedItems query All client side code (javascript/css/images) is done and tested as part of Plone Mockup project.

plone.app.workflowmanager-2.0b1-1.lbn19.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.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.dexterity-1.0.2-3.lbn25.noarch

Grok-like directives for creating Dexterity content

plone.multilingual-1.2.1-1.lbn19.noarch

NOT in development. This package is beeing merged on plone.app.multilingual .. image:: https://travis-ci.org/plone/plone.multilingual.png :target: http://travis-ci.org/plone/plone.multilingual plone.multilingual ================== This package contains the core functionality for the next generation multilingual engine. These are the main artifacts and its purposes: canonical: * the canonical organizes the information about a "translation-group" * it's using a dictionary with language-codes as keys and uuids (provided by plone.uuid) as values storage: * persistent storage, which holds the canonicals in an IOBTree * the OOBTree's key is the UUID of the content, the according value is the canonical manager: * adapter for ITranslatable * provides the translations API adapters: * ITranslationLocator - where to put a translation * ITranslationIdChooser - generates a valid id for a translation * ITranslationCloner - copy the language-independent content to the translation * ITranslationFactory - creates the translation In order to have a test we have a type called Demo that has an adapter called DemoLanguage that will allow to get the language of the object:: >>> from plone.multilingual.interfaces import ITranslationManager >>> from plone.multilingual.interfaces import ILanguage >>> from plone.app.testing import setRoles, login, TEST_USER_ID, TEST_USER_NAME >>> from zope.lifecycleevent import modified >>> portal = layer['portal'] >>> setRoles(portal, TEST_USER_ID, ['Manager']) >>> login(portal, TEST_USER_NAME) >>> portal.invokeFactory('Folder', 'ob1', title=u"An archetypes based folder") 'ob1' >>> ILanguage(portal['ob1']).set_language('ca') >>> portal['ob1'].reindexObject() >>> modified(portal['ob1']) Ensuring that the new object gets its UUID:: >>> from plone.uuid.interfaces import IUUID >>> ob1_uuid = IUUID(portal['ob1']) >>> isinstance(ob1_uuid, str) True We create a new translation in 'en' language:: >>> ITranslationManager(portal['ob1']).add_translation('en') We try to create a new translation in 'ca' that already exists:: >>> ITranslationManager(portal['ob1']).add_translation('ca') Traceback (most recent call last): ... KeyError: 'Translation already exists' We try to create a new translation without language:: >>> ITranslationManager(portal['ob1']).add_translation(None) Traceback (most recent call last): ... KeyError: 'There is no target language' We get the 'en' translation:: >>> ITranslationManager(portal['ob1']).get_translation('en') <ATFolder at /plone/ob1-en> >>> ILanguage(ITranslationManager(portal['ob1']).get_translation('en')).get_language() == 'en' True let's get all the translations:: >>> ITranslationManager(portal['ob1']).get_translations() {'ca': <ATFolder at /plone/ob1>, 'en': <ATFolder at /plone/ob1-en>} let's get only the languages:: >>> ITranslationManager(portal['ob1']).get_translated_languages() ['ca', 'en'] has_translation:: >>> ITranslationManager(portal['ob1']).has_translation('en') True >>> ITranslationManager(portal['ob1']).has_translation('it') False register_translation with invalid language:: >>> ITranslationManager(portal['ob1']).remove_translation('en') >>> ITranslationManager(portal['ob1']).register_translation(None, portal['ob1-en']) Traceback (most recent call last): ... KeyError: 'There is no target language' register a translation with content:: >>> ITranslationManager(portal['ob1']).register_translation('en', portal['ob1-en']) >>> ITranslationManager(portal['ob1']).get_translations() {'ca': <ATFolder at /plone/ob1>, 'en': <ATFolder at /plone/ob1-en>} changing the content-language (there should act a subscriber):: >>> ILanguage(portal['ob1-en']).set_language('it') >>> from zope.event import notify >>> from zope.lifecycleevent import ObjectModifiedEvent >>> notify(ObjectModifiedEvent(portal['ob1-en'])) >>> ITranslationManager(portal['ob1']).get_translations() {'ca': <ATFolder at /plone/ob1>, 'it': <ATFolder at /plone/ob1-en>} test more translations:: >>> obj_it = ITranslationManager(portal['ob1']).get_translation('it') >>> ITranslationManager(obj_it).add_translation('fr') >>> ITranslationManager(obj_it).add_translation('pt') >>> ITranslationManager(portal['ob1']).get_translated_languages() ['ca', 'it', 'fr', 'pt'] >>> ITranslationManager(obj_it).get_translated_languages() ['ca', 'it', 'fr', 'pt'] test if canonicals objects are the same:: >>> obj_ca = ITranslationManager(obj_it).get_translation('ca') >>> canonical_it = ITranslationManager(obj_it).query_canonical() >>> canonical_ca = ITranslationManager(obj_ca).query_canonical() >>> canonical_it == canonical_ca True Messing up with content ----------------------- In case that we do mess up things with content (users always do):: >>> from zope.lifecycleevent import modified >>> portal.invokeFactory('Folder', 'ob2', title=u"An archetypes based doc") 'ob2' >>> ILanguage(portal['ob2']).set_language('it') >>> modified(portal['ob2']) >>> ILanguage(portal['ob2']).get_language() 'it' >>> ITranslationManager(portal['ob2']).add_translation('en') >>> ob2_en = ITranslationManager(portal['ob2']).get_translation('en') >>> portal.invokeFactory('Folder', 'ob3', title=u"An archetypes based doc") 'ob3' >>> ILanguage(portal['ob3']).set_language('it') >>> modified(portal['ob3']) >>> ILanguage(portal['ob3']).get_language() 'it' >>> ITranslationManager(portal['ob3']).add_translation('es') >>> ob3_es = ITranslationManager(portal['ob3']).get_translation('es') >>> from OFS.event import ObjectWillBeRemovedEvent >>> notify(ObjectWillBeRemovedEvent(portal['ob2'])) >>> portal.manage_delObjects('ob2') >>> notify(ObjectWillBeRemovedEvent(ob3_es)) >>> portal.manage_delObjects(ob3_es.id) >>> c_old = ITranslationManager(portal['ob3']).query_canonical() >>> c_new = ITranslationManager(ob2_en).query_canonical() >>> c_old == c_new False >>> isinstance(c_old, str) True >>> isinstance(c_new, str) True >>> ITranslationManager(ob2_en).register_translation('it', portal['ob3']) >>> c1 = ITranslationManager(portal['ob3']).query_canonical() >>> c2 = ITranslationManager(ob2_en).query_canonical() >>> c1 == c2 True Other use case, A('it' + 'en') and B('it' + 'es'), and we want A('en') -> B('es'):: >>> portal.invokeFactory('Folder', 'mess1', title=u"An archetypes based doc") 'mess1' >>> ILanguage(portal['mess1']).set_language('it') >>> modified(portal['mess1']) >>> ILanguage(portal['mess1']).get_language() 'it' >>> ITranslationManager(portal['mess1']).add_translation('en') >>> mess1_en = ITranslationManager(portal['mess1']).get_translation('en') >>> portal.invokeFactory('Folder', 'mess2', title=u"An archetypes based doc") 'mess2' >>> ILanguage(portal['mess2']).set_language('it') >>> ITranslationManager(portal['mess2']).add_translation('es') >>> mess2_es = ITranslationManager(portal['mess2']).get_translation('es') >>> ITranslationManager(mess1_en).register_translation('es', mess2_es) >>> ITranslationManager(portal['mess2']).get_translation('es') >>> ITranslationManager(portal['mess1']).get_translation('es') <ATFolder at /plone/mess2-es> Default-Adapters ---------------- id-chooser:: >>> from plone.multilingual.interfaces import ITranslationIdChooser >>> chooser = ITranslationIdChooser(portal['ob1-en']) >>> chooser(portal, 'es') 'ob1-es' locator:: >>> ITranslationManager(portal['ob1']).add_translation('es') >>> child_id = portal.ob1.invokeFactory('Folder', 'ob1_child', language="ca") >>> from plone.multilingual.interfaces import ITranslationLocator >>> locator = ITranslationLocator(portal['ob1-en']) >>> locator('es') == portal True >>> child_locator = ITranslationLocator(portal.ob1.ob1_child) >>> child_locator('es') == portal['ob1-es'] True >>> ITranslationManager(portal['ob1']).remove_translation('es') Convert intids to uuids upgrade step ------------------------------------ An upgrade step is available in case of having an existing site with the experimental 0.1 plone.multilingual version:: >>> from plone.multilingual.upgrades.to02 import upgrade .. note:: You must reinstall the plone.multilingual package in order to install the required new utility in place before upgrading. If you are using a version of Dexterity below 2.0, you must install the package plone.app.referenceablebehavior and enable the *Referenceable* (plone.app.referenceablebehavior.referenceable.IReferenceable) behavior for all your Dexterity content types before you attempt to upgrade your site. You can run the @@pml-upgrade view at the root of your site or follow the upgrade step in portal_setup > upgrades. If you can't see the upgrade step, press *Show old upgrades* and select the *Convert translation based intids to uuids (0.1 → 02)* Upgrade to catalog ------------------ :: >>> from plone.multilingual.upgrades.to03 import upgrade we shouldn't find the storage-utility anymore:: >>> from plone.multilingual.interfaces import IMultilingualStorage >>> gsm = portal.getSiteManager() >>> gsm.queryUtility(IMultilingualStorage) is None True