[Testbot] Plone 5.0 - Python 2.7 - Build # 3790 - Still failing! - 0 failure(s)
jenkins at plone.org
jenkins at plone.org
Tue Dec 2 12:14:44 UTC 2014
-------------------------------------------------------------------------------
Plone 5.0 - Python 2.7 - Build # 3790 - Still Failing!
-------------------------------------------------------------------------------
http://jenkins.plone.org/job/plone-5.0-python-2.7/3790/
-------------------------------------------------------------------------------
CHANGES
-------------------------------------------------------------------------------
Repository: plone.dexterity
Branch: refs/heads/master
Date: 2014-11-11T10:58:01+01:00
Author: Jens W. Klein (jensens) <jk at kleinundpartner.at>
Commit: https://github.com/plone/plone.dexterity/commit/cbf9dbe3f333efeb196ee7773b4323c547950b54
minor housekeeping leftovers: adapts->@adapter, each import on one line
Files changed:
M plone/dexterity/browser/edit.py
M plone/dexterity/browser/traversal.py
diff --git a/plone/dexterity/browser/edit.py b/plone/dexterity/browser/edit.py
index 87013b6..338df61 100644
--- a/plone/dexterity/browser/edit.py
+++ b/plone/dexterity/browser/edit.py
@@ -9,7 +9,8 @@
from plone.dexterity.interfaces import IDexterityEditForm
from plone.dexterity.interfaces import IDexterityFTI
from plone.z3cform import layout
-from z3c.form import form, button
+from z3c.form import button
+from z3c.form import form
from zope.component import getUtility
from zope.event import notify
from zope.interface import classImplements
diff --git a/plone/dexterity/browser/traversal.py b/plone/dexterity/browser/traversal.py
index 1321e03..c7b93a0 100644
--- a/plone/dexterity/browser/traversal.py
+++ b/plone/dexterity/browser/traversal.py
@@ -6,7 +6,7 @@
from plone.dexterity.interfaces import DAV_FOLDER_DATA_ID
from plone.dexterity.interfaces import IDexterityContent
from webdav.NullResource import NullResource
-from zope.component import adapts
+from zope.component import adapter
from zope.publisher.interfaces.browser import IBrowserRequest
try:
@@ -15,6 +15,7 @@
from ZPublisher.BaseRequest import DefaultPublishTraverse
+ at adapter(IDexterityContent, IBrowserRequest)
class DexterityPublishTraverse(DefaultPublishTraverse):
"""Override the default browser publisher to make WebDAV work for
Dexterity objects.
@@ -24,8 +25,6 @@ class DexterityPublishTraverse(DefaultPublishTraverse):
pseudo-resource that is shown for folderish content items.
"""
- adapts(IDexterityContent, IBrowserRequest)
-
def __init__(self, context, request):
self.context = context
self.request = request
Repository: plone.dexterity
Branch: refs/heads/master
Date: 2014-11-19T15:42:55+01:00
Author: Jens W. Klein (jensens) <jk at kleinundpartner.at>
Commit: https://github.com/plone/plone.dexterity/commit/ebc78101c6da7908c683b301db9f783c10d2ae92
Merge remote-tracking branch 'remotes/origin/master'
Files changed:
M README.rst
diff --git a/README.rst b/README.rst
index 01f5742..7c00d13 100644
--- a/README.rst
+++ b/README.rst
@@ -3,94 +3,68 @@ Dexterity
"Same, same, but different"
-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.
+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.
+- 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.
+- 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.
+- 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.
+- 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.
+- 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:
+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.
+ 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 specialised
- packages, each of which is independently tested and reusable. Furthermore,
- packages should have as few dependencies as possible, and should declare
- their dependencies explicitly. This helps keep the design clean and the
- code manageable.
+ Mega-frameworks be damned.
+ Dexterity consists of a number of specialised packages, each of which is independently tested and reusable.
+ Furthermore, packages should have 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.
+ 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.
- 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.
+ZCA over old Zope 2
+ As many components as possible should work with plain ZCA (Zope Component Architecture, ``zope.*`` packages with origins in Zope 3).
+ Although Dexterity does not pretend to work with non-CMF systems,
+ Even where there are dependencies on Zope 2, CMF or Plone, they should - as far as is practical - follow ZCA 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
+ ZCA 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.
+ We want Dexterity to be "Zope-ish" (and really, "ZCA-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.
+ "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.
What's it all about?
--------------------
@@ -99,141 +73,99 @@ With the waffle out of the way, let's look in a bit more detail about what
makes up a "content type" in the Dexterity system.
The model
+ The Dexterity "model" describes a type's schemata and metadata associated with those schemata.
+ A schema is just a series of fields that can be used to render add/edit forms and introspect an object of the given type.
+ The metadata storage is extensible via the component architecture.
+ Typical forms of metadata include UI hints such as specifying the type of widget to use when rendering a particular field, and per-field security settings.
- The Dexterity "model" describes a type's schemata (most types will have
- only one) and metadata associated with those schemata. A schema is just
- a series of fields that can be used to render add/edit forms and
- introspect an object of the given type. The metadata storage is extensible
- via the component architecture. Typical forms of metadata include UI
- hints such as specifying the type of widget to use when rendering a
- particular field, and per-field security settings.
-
- The model is typically described in XML, though at runtime it is an
- instance of an object providing the IModel interface from
- plone.supermodel. Schemata in the model are interfaces with zope.schema
- fields.
-
- The model can exist purely as data in the ZODB if a type is created
- through-the-web. Alternatively, it can be loaded from a file. The XML
- representation is intended to be human-readable and self-documenting.
- It is also designed with tools like ArchGenXML and Genesis in mind,
- that can generate models from a visual representation.
+ The model is described in also XML.
+ Though at runtime it is an instance of an object providing the IModel interface from ``plone.supermodel``.
+ Schemata in the model are interfaces with ``zope.schema`` fields.
-The schema
+ The model can exist purely as data in the ZODB if a type is created through-the-web.
+ Alternatively, it can be loaded from a file.
+ The XML representation is intended to be human-readable and self-documenting.
+ It is also designed with tools like `AGX <http://agx.me>`_ in mind, that can generate models from a visual representation.
- All content types have at least one (unnamed) schema. A schema is
- simply an Interface with zope.schema fields. The schema can be specified
- in Python code (in which case it is simply referenced by name), or it
- can be loaded from an XML model.
+The schema
+ All content types have at least one (unnamed) schema.
+ A schema is simply an Interface with zope.schema fields.
+ The schema can be specified in Python code (in which case it is simply referenced by name), or it can be loaded from an XML model.
- The unnamed schema is also known as the IContentType schema, in that the
- schema interface will provide the Zope 3 IContentType interface. This
- means that if you call queryContentType() on a Dexterity content object,
- you should get back its unnamed schema, and that schema should be
- provided by the object that was queried. Thus, the object will directly
- support the attributes promised by the schema. This makes Dexterity
- content objects "Pythonic" and easy to work with.
+ The unnamed schema is also known as the IContentType schema.
+ In that, the schema interface will provide the zope IContentType interface.
+ This means that if you call ``queryContentType()`` on a Dexterity content object, you should get back its unnamed schema, and that schema should be provided by the object that was queried.
+ Thus, the object will directly support the attributes promised by the schema.
+ This makes Dexterity content objects "Pythonic" and easy to work with.
The class
-
Of course, all content objects are instances of a particular class.
- It is easy to provide your own class, and Dexterity has convenient
- base classes for you to use. However, many types will not need a class
- at all. Instead, they will use the standard Dexterity "Item" and
- "Container" classes.
-
- Dexterity's content factory will initialise an object of one of these
- classes with the fields in the type's content schema, and will ensure
- that objects provide the relevant interfaces, including the schema
- interface itself.
-
- The preferred way to add behaviour and logic to Dexterity content objects
- is via adapters. In this case, you will probably want a filesystem
- version of the schema interface (this can still be loaded from XML if you
- wish, but it will have an interface with a real module path) that you
- can register components against.
+ It is easy to provide your own class, and Dexterity has convenient base classes for you to use.
+ However, many types will not need a class at all.
+ Instead, they will use the standard Dexterity "Item" and "Container" classes.
-The factory
+ Dexterity's content factory will initialise an object of one of these classes with the fields in the type's content schema.
+ The factory will ensure that objects provide the relevant interfaces, including the schema interface itself.
- Dexterity content is constructed using a standard Zope 3 IFactory
- named utility. By convention the factory utility has the same name as the
- portal_type of the content type.
+ The preferred way to add behaviour and logic to Dexterity content objects is via adapters.
+ In this case, you will probably want a filesystem version of the schema interface (this can still be loaded from XML if you
+ wish, but it will have an interface with a real module path) that you can register components against.
- When a Dexterity FTI (Factory Type Information, see below) is created,
- an appropriate factory will be registered as a local utility unless one
- with that name already exists.
+The factory
+ Dexterity content is constructed using a standard zope IFactory named utility.
+ By convention the factory utility has the same name as the portal_type of the content type.
- The default factory is capable of initialising a generic 'Item' or
- 'Container' object to exhibit a content type schema and have the
- security and other aspects specified in the type's model. You can use
- this if you wish, or provide your own factory.
+ When a Dexterity FTI (Factory Type Information, see below) is created, an appropriate factory will be registered as a local utility unless one with that name already exists.
-Views
+ The default factory is capable of initialising a generic ``Item`` or ``Container`` object to exhibit a content type schema and have the security and other aspects specified in the type's model.
+ You can use this if you wish, or provide your own factory.
- Dexterity will by default create an add view (registered as a local
- utility, since it needs to take the portal_type of the content type into
- account when determining what fields to render) and an edit view (
- registered as a generic, global view, which inspects the context's
- portal_type at runtime) for each type. There is also a default main
- view, which simply outputs the fields set on the context.
+Views
+ Dexterity will by default create an:
+ - add view (registered as a local utility, since it needs to take the portal_type of the content type into account when determining what fields to render) and an
+ - edit view (registered as a generic, global view, which inspects the context's portal_type at runtime) for each type.
+ - A default main view exists, which simply outputs the fields set on the context.
- To register new views, you will normally need a filesystem schema
- interface. You can then register views for this interface as you
- normally would.
+ To register new views, you will normally need a filesystem schema interface.
+ You can then register views for this interface as you normally would.
- If you need to override the default add view, create a view for IAdding
- with a name corresponding to the portal_type of the content type.
- This will prevent Dexterity from registering a local view with the same
- name when the FTI is created.
+ If you need to override the default add view, create a view for IAdding with a name corresponding to the portal_type of the content type.
+ This will prevent Dexterity from registering a local view with the same name when the FTI is created.
The Factory Type Information (FTI)
+ The FTI holds various information about the content type.
+ Many operations performed by the Dexterity framework begin by looking up the type's FTI to find out some information about the type.
- The FTI holds various information about the content type. Many operations
- performed by the Dexterity framework begin by looking up the type's
- FTI to find out some information about the type.
-
- The FTI is an object stored in portal_types in the ZMI. Most settings can
- be changed through the web. See the IDexterityFTI interface for more
- information.
+ The FTI is an object stored in portal_types in the ZMI.
+ Most settings can be changed through the web.
+ See the IDexterityFTI interface for more information.
- When a Dexterity FTI is created, an event handler will create a few
- local components, including the factory utility and add view for the
- new type. The FTI itself is also registered as a named utility, to
- make it easy to look up using syntax like:
+ When a Dexterity FTI is created, an event handler will create a few local components, including the factory utility and add view for the new type. The FTI itself is also registered as a named utility, to make it easy to look up using syntax like::
getUtility(IDexterityFTI, name=portal_type)
The FTI is also fully importable and exportable using GenericSetup.
- Thus, the easiest way to create and distribute a content type is to
- create a new FTI, set some properties (including a valid XML model,
- which can be entered TTW if there is no file or schema interface to use),
- and export it as a GenericSetup extension profile.
+ Thus, the easiest way to create and distribute a content type is to create a new FTI, set some properties (including a valid XML model,
+ which can be entered TTW if there is no file or schema interface to use), and export it as a GenericSetup extension profile.
Behaviors
+ Behaviors are a way write make re-usable bits of functionality that can be toggled on or off on a per-type basis.
+ Examples may include common metadata, or common functionality such as locking, tagging or ratings.
- Behaviors are a way write make re-usable bits of functionality that can
- be toggled on or off on a per-type basis. Examples may include common
- metadata, or common functionality such as locking, tagging or ratings.
+ Behaviors are implemented using the plone.behavior package.
+ See its documentation for more details about how to write your own behaviors.
- Behaviors are implemented using the plone.behavior package. See its
- documentation for more details about how to write your own behaviors.
+ In Dexterity, behaviors can "inject" fields into the standard add and edit forms, and may provide marker interfaces for newly created objects.
+ See the example.dexterity package for an example of a behavior that provides form fields.
- In Dexterity, behaviors can "inject" fields into the standard add and edit
- forms, and may provide marker interfaces for newly created objects. See
- the example.dexterity package for an example of a behavior that provides
- form fields.
-
- In use, a behavior is essentially just an adapter that only appears to be
- registered if the behavior is enabled in the FTI of the object being
- adapted. Thus, if you have a behavior described by my.package.IMyBehavior,
- you'll typically interact with this behavior by doing::
+ In use, a behavior is essentially just an adapter that only appears to be registered if the behavior is enabled in the FTI of the object being adapted.
+ Thus, if you have a behavior described by my.package.IMyBehavior, you'll typically interact with this behavior by doing::
my_behavior = IMyBehavior(context, None)
if my_behavior is not None:
...
- The enabled behaviors for a given type are kept in the FTI, as a
- list of dotted interface names.
+ The enabled behaviors for a given type are kept in the FTI, as a list of dotted interface names.
The Dexterity Ecosystem
-----------------------
@@ -244,83 +176,52 @@ Zope and CMF.
The most important packages are:
-plone.alterego (Python)
-
- Support for dynamic modules that create objects on the fly. Dexterity
- uses this to dynamically create "real" interfaces for types that exist
- only through-the-web. This allows these types to have a proper
- IContentType schema, and allows local adapters to be registered for
- this interface (e.g. a custom view with a template defined through the
- web).
-
- Note that if a type uses a filesystem interface (whether written manually
- or loaded from an XML model), this module is not used.
-
-plone.supermodel (Zope 3)
-
- Supports parsing and serialisation of interfaces from/to XML. The XML
- format is based directly on the interfaces that describe zope.schema type
- fields, and is thus easily extensible to new field types. This has the
- added benefit that the interface documentation in the zope.schema package
- applies to the XML format as well.
+`plone.dexterity <https://pypi.python.org/pypi/plone.alterego>`_ (CMF)
+ **this package** Defines the FTI and content classes.
+ It provides basic views (with forms based on z3c.form), handles security and so on.
+ It also provides components to orchestrate the various functionality provided by the packages above in order to bring the Dexterity system together.
- Supermodel is extensible via adapters and XML namespaces. plone.dexterity
- uses this to allow security and UI hints to be embedded as metadata in the
- XML model.
+`plone.behavior <https://pypi.python.org/pypi/plone.behavior>`_ (ZCA)
+ Supports "conditional" adapters. A product author can write and register a generic behaviour that works via a simple adapter.
+ The adapter will appear to be registered for types that have the named behaviour available.
-plone.behavior (Zope 3)
+ Dexterity wires this up in such a way that the list of enabled behaviours is stored as a property in the FTI.
+ This makes it easy to add/remove behaviours through the web, or using GenericSetup at install time.
- Supports "conditional" adapters. A product author can write and register
- a generic behaviour that works via a simple adapter. The adapter will
- appear to be registered for types that have the named behaviour
- available.
-
- Dexterity wires this up in such a way that the list of enabled behaviours
- is stored as a property in the FTI. This makes it easy to add/remove
- behaviours through the web, or using GenericSetup at install time.
-
-plone.folder (CMF)
-
- This is an implementation of an ordered, BTree-backed folder, with Zope 3
+`plone.folder <https://pypi.python.org/pypi/plone.folder>`_ (CMF)
+ This is an implementation of an ordered, BTree-backed folder, with ZCA
dictionary-style semantics for managing content items inside the folder.
The standard Dexterity 'Container' type uses plone.folder as its base.
-plone.autoform (CMF)
-
- Contains helper functions to construct forms based on tagged values stored
- on schema interfaces.
-
-plone.directives.form (CMF)
-
- Adds convention-over-configuration support for plone.supermodel schemata
- and plone.autoform form hints.
+`plone.autoform <https://pypi.python.org/pypi/plone.autoform>`_ (CMF, z3cform)
+ Contains helper functions to construct forms based on tagged values stored on schema interfaces.
-plone.dexterity (CMF)
+`plone.supermodel <https://pypi.python.org/pypi/plone.supermodel>`_ (ZCA)
+ Supports parsing and serialisation of interfaces from/to XML.
+ The XML format is based directly on the interfaces that describe zope.schema type fields.
+ Thus it is easily extensible to new field types.
+ This has the added benefit that the interface documentation in the zope.schema package applies to the XML format as well.
- This package defines the FTI and content classes, provides basic views
- (with forms based on z3c.form), handles security and so on. It also
- provides components to orchestrate the various functionality provided
- by the packages above in order to bring the Dexterity system together.
+ Supermodel is extensible via adapters and XML namespaces.
+ plone.dexterity uses this to allow security and UI hints to be embedded as metadata in the XML model.
-plone.directives.dexterity (CMF)
+`plone.alterego <https://pypi.python.org/pypi/plone.alterego>`_ (Python)
+ Support for dynamic modules that create objects on the fly.
+ Dexterity uses this to generate "real" interfaces for types that exist only through-the-web.
+ This allows these types to have a proper IContentType schema.
+ It also allows local adapters to be registered for this interface (e.g. a custom view with a template defined through the web).
- Adds convention-over-configuration support for Dexterity content and
- add/edit forms.
+ Note that if a type uses a filesystem interface (whether written manually or loaded from an XML model), this module is not used.
-plone.app.dexterity (Plone)
+`plone.app.dexterity <https://pypi.python.org/pypi/plone.app.dexterity>`_ (Plone)
+ This package contains all Plone-specific aspects of Dexterity, including Ploneish UI components, behaviours and defaults.
- This package contains all Plone-specific aspects of Dexterity, including
- Ploneish UI components, behaviours and defaults.
-Usage examples
---------------
+Developer Manual
+----------------
-Take a look at the example.dexterity package, which can be found in the
-Plone Collective (http://dev.plone.org/collective), for examples of various
-ways to use Dexterity.
+The `Dexterity Developer Manual <http://docs.plone.org/external/plone.app.dexterity/docs/index.html>`_ is a complete documentation with practical examples and part of the `Offical Plone Documentation <http://docs.plone.org/>`_.
-See also Dexterity's pages on plone.org (http://plone.org/products/dexterity)
-where you will also find extensive documentation.
Source Code
===========
-------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CHANGES.log
Type: application/octet-stream
Size: 28644 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-testbot/attachments/20141202/799454ce/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.log
Type: application/octet-stream
Size: 110729 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-testbot/attachments/20141202/799454ce/attachment-0003.obj>
More information about the Testbot
mailing list