Search results

plone.testing-4.0.10-1.lbn13.noarch

Testing infrastructure for Zope and Plone projects.

plone.testing-5.1-1.lbn25.noarch

plone.testing provides tools for writing unit and integration tests in a Zope and Plone environment. It is not tied to Plone, and it does not depend on Zope 2 (although it has some optional Zope 2-only features). plone.testing builds on zope.testing, in particular its layers concept. This package also aims to promote some “good practice” for writing tests of various types. Note If you are working with Plone, there is a complementary package plone.app.testing, which builds on plone.testing to provide additional layers useful for testing Plone add-ons.

plone.testing-5.1-1.lbn25.noarch

plone.testing provides tools for writing unit and integration tests in a Zope and Plone environment. It is not tied to Plone, and it does not depend on Zope 2 (although it has some optional Zope 2-only features). plone.testing builds on zope.testing, in particular its layers concept. This package also aims to promote some “good practice” for writing tests of various types. Note If you are working with Plone, there is a complementary package plone.app.testing, which builds on plone.testing to provide additional layers useful for testing Plone add-ons.

plone.theme-2.1.5-1.lbn25.noarch

This package lets you mark the request with a "layer" interface conditional on the currently selected skin (theme) in the portal_skins tool. Most Zope 3 "visual" directives, like <browser:page /> or <browser:viewlet /> accept a 'layer' attribute, which should point to an interface. Recall that a view is a multi-adapter on (context, request). Most views are registered so that the 'request' being adapted only needs to provide Interface. This is equivalent to saying layer="*". By applying a marker interface to the request, and registering a view or viewlet with this interface as the adapted 'layer', we can override a more general view, or make a viewlet that is only shown for a particular layer. In the context of CMF and Plone, we'd like to tie the layer to the current skin selection. We do that by name. What you have to do First, you should create a marker interface: >>> from zope.interface import Interface >>> class IMyTheme(Interface): ... """Marker interface for skins part of 'My Theme' ... """ Then, register this as a theme layer in ZCML: <interface interface=".interfaces.IMyTheme" type="zope.publisher.interfaces.browser.IBrowserSkinType" name="My Theme" /> The title here must match the name of the theme/skin selection in portal_skins. How it works Behind the scenes, the <interface /> registration marks IMyTheme with the "IInterface" IThemelayer, and registers IMyTheme as a utility named "My Theme" and providing IBrowserSkinType. We do something to this effect in tests/tests.zcml. Let us define the "My Theme" skin selection: >>> from Products.CMFCore.utils import getToolByName >>> portal_skins = getToolByName(self.portal, 'portal_skins') >>> default_skin = portal_skins.getDefaultSkin() >>> skin_path = portal_skins._getSelections()[default_skin] >>> portal_skins.addSkinSelection('My Theme', skin_path) In tests/tests.zcml we have registered two version of a view called @@layer-test-view. One, for the default skin layer, simply outputs "Default". The other outputs "My Theme". Before we turn on the skin, we will get the default view. >>> from Products.Five.testbrowser import Browser >>> browser = Browser() >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents Default However, if we turn the skin on, we should see the effects of the marker interface being applied. >>> portal_skins.default_skin = 'My Theme' >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents My Theme And if we switch back: >>> portal_skins.default_skin = 'Plone Default' >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents Default

plone.theme-2.1.5-1.lbn25.noarch

This package lets you mark the request with a "layer" interface conditional on the currently selected skin (theme) in the portal_skins tool. Most Zope 3 "visual" directives, like <browser:page /> or <browser:viewlet /> accept a 'layer' attribute, which should point to an interface. Recall that a view is a multi-adapter on (context, request). Most views are registered so that the 'request' being adapted only needs to provide Interface. This is equivalent to saying layer="*". By applying a marker interface to the request, and registering a view or viewlet with this interface as the adapted 'layer', we can override a more general view, or make a viewlet that is only shown for a particular layer. In the context of CMF and Plone, we'd like to tie the layer to the current skin selection. We do that by name. What you have to do First, you should create a marker interface: >>> from zope.interface import Interface >>> class IMyTheme(Interface): ... """Marker interface for skins part of 'My Theme' ... """ Then, register this as a theme layer in ZCML: <interface interface=".interfaces.IMyTheme" type="zope.publisher.interfaces.browser.IBrowserSkinType" name="My Theme" /> The title here must match the name of the theme/skin selection in portal_skins. How it works Behind the scenes, the <interface /> registration marks IMyTheme with the "IInterface" IThemelayer, and registers IMyTheme as a utility named "My Theme" and providing IBrowserSkinType. We do something to this effect in tests/tests.zcml. Let us define the "My Theme" skin selection: >>> from Products.CMFCore.utils import getToolByName >>> portal_skins = getToolByName(self.portal, 'portal_skins') >>> default_skin = portal_skins.getDefaultSkin() >>> skin_path = portal_skins._getSelections()[default_skin] >>> portal_skins.addSkinSelection('My Theme', skin_path) In tests/tests.zcml we have registered two version of a view called @@layer-test-view. One, for the default skin layer, simply outputs "Default". The other outputs "My Theme". Before we turn on the skin, we will get the default view. >>> from Products.Five.testbrowser import Browser >>> browser = Browser() >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents Default However, if we turn the skin on, we should see the effects of the marker interface being applied. >>> portal_skins.default_skin = 'My Theme' >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents My Theme And if we switch back: >>> portal_skins.default_skin = 'Plone Default' >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents Default

plone.tiles-1.2-1.lbn13.noarch

For the purposes of this package, a tile is a browser view and an associated utility providing some metadata about that view. The metadata includes a title and description, an 'add' permission and optionally a schema interface describing configurable aspects of the tile. The idea is that a UI (such as Deco) can present the user with a list of insertable tiles and optionally render a form to configure the tile upon insertion. A tile is inserted into a layout as a link: <link rel="tile" target="placeholder" href="./@@sample.tile/tile1?option1=value1" /> The sub-path (tile1` in this case) is used to set the tile id attribute. This allows the tile to know its unique id, and, in the case of persistent tiles, look up its data. sample.tile is the name of the browser view that implements the tile. This is made available as the __name__ attribute. Other parameters may be turned into tile data, available under the data attribute, a dict, for regular tiles. For persistent tiles (those deriving from the PersistentTile base class), the data is fetched from annotations instead, based on the tile id. There are three interfaces describing tiles in this package: * IBasicTile is the low-level interface for tiles. It extends IBrowserView to describe the semantics of the __name__ and id attributes. * ITile describes a tile that can be configured with some data. The data is accessible via a dict called data. The default implementation of this interface, plone.tiles.Tile, will use the schema of the tile type and the query string (self.request.form) to construct that dictionary. This interface also describes an attribute url, which gives the canonical tile URL, including the id sub-path and any query string parameters. (Note that tiles also correctly implement IAbsoluteURL.) * IPersistentTile describes a tile that stores its configuration in object annotations, and is needed when configuration values cannot be encoded into a query string. The default implementation is in plone.tiles.PersistentTile. To make it possible to have several tiles of a given type on the same layout, the annotations are keyed by the tile __name__. In addition, tiles are described by ITileType, which contains attributes for the tile name, title, description, add permission and schema (if required). A properly configured tile, then, consists of a browser view providing IBasicTile or one of its derivatives, and a utility providing ITileType with the same name as the tile browser view. There is a convenience ZCML directive - <plone:tile /> - to register both of these components in one go. To support creation of appropriate tile links, plone.tiles.data contains two methods - encode() and decode() - to help turn a data dictionary into a query string and turn a request.form dict into a data dict that complies with a tile's schema interface.

plone.tiles-1.8.1-1.lbn25.noarch

For the purposes of this package, a tile is a browser view and an associated utility providing some metadata about that view. The metadata includes a title and description, an 'add' permission and optionally a schema interface describing configurable aspects of the tile. The idea is that a UI (such as Deco) can present the user with a list of insertable tiles and optionally render a form to configure the tile upon insertion. A tile is inserted into a layout as a link: <link rel="tile" target="placeholder" href="./@@sample.tile/tile1?option1=value1" /> The sub-path (tile1` in this case) is used to set the tile id attribute. This allows the tile to know its unique id, and, in the case of persistent tiles, look up its data. sample.tile is the name of the browser view that implements the tile. This is made available as the __name__ attribute. Other parameters may be turned into tile data, available under the data attribute, a dict, for regular tiles. For persistent tiles (those deriving from the PersistentTile base class), the data is fetched from annotations instead, based on the tile id. There are three interfaces describing tiles in this package: * IBasicTile is the low-level interface for tiles. It extends IBrowserView to describe the semantics of the __name__ and id attributes. * ITile describes a tile that can be configured with some data. The data is accessible via a dict called data. The default implementation of this interface, plone.tiles.Tile, will use the schema of the tile type and the query string (self.request.form) to construct that dictionary. This interface also describes an attribute url, which gives the canonical tile URL, including the id sub-path and any query string parameters. (Note that tiles also correctly implement IAbsoluteURL.) * IPersistentTile describes a tile that stores its configuration in object annotations, and is needed when configuration values cannot be encoded into a query string. The default implementation is in plone.tiles.PersistentTile. To make it possible to have several tiles of a given type on the same layout, the annotations are keyed by the tile __name__. In addition, tiles are described by ITileType, which contains attributes for the tile name, title, description, add permission and schema (if required). A properly configured tile, then, consists of a browser view providing IBasicTile or one of its derivatives, and a utility providing ITileType with the same name as the tile browser view. There is a convenience ZCML directive - <plone:tile /> - to register both of these components in one go. To support creation of appropriate tile links, plone.tiles.data contains two methods - encode() and decode() - to help turn a data dictionary into a query string and turn a request.form dict into a data dict that complies with a tile's schema interface.

plone.tiles-1.8.1-1.lbn25.noarch

For the purposes of this package, a tile is a browser view and an associated utility providing some metadata about that view. The metadata includes a title and description, an 'add' permission and optionally a schema interface describing configurable aspects of the tile. The idea is that a UI (such as Deco) can present the user with a list of insertable tiles and optionally render a form to configure the tile upon insertion. A tile is inserted into a layout as a link: <link rel="tile" target="placeholder" href="./@@sample.tile/tile1?option1=value1" /> The sub-path (tile1` in this case) is used to set the tile id attribute. This allows the tile to know its unique id, and, in the case of persistent tiles, look up its data. sample.tile is the name of the browser view that implements the tile. This is made available as the __name__ attribute. Other parameters may be turned into tile data, available under the data attribute, a dict, for regular tiles. For persistent tiles (those deriving from the PersistentTile base class), the data is fetched from annotations instead, based on the tile id. There are three interfaces describing tiles in this package: * IBasicTile is the low-level interface for tiles. It extends IBrowserView to describe the semantics of the __name__ and id attributes. * ITile describes a tile that can be configured with some data. The data is accessible via a dict called data. The default implementation of this interface, plone.tiles.Tile, will use the schema of the tile type and the query string (self.request.form) to construct that dictionary. This interface also describes an attribute url, which gives the canonical tile URL, including the id sub-path and any query string parameters. (Note that tiles also correctly implement IAbsoluteURL.) * IPersistentTile describes a tile that stores its configuration in object annotations, and is needed when configuration values cannot be encoded into a query string. The default implementation is in plone.tiles.PersistentTile. To make it possible to have several tiles of a given type on the same layout, the annotations are keyed by the tile __name__. In addition, tiles are described by ITileType, which contains attributes for the tile name, title, description, add permission and schema (if required). A properly configured tile, then, consists of a browser view providing IBasicTile or one of its derivatives, and a utility providing ITileType with the same name as the tile browser view. There is a convenience ZCML directive - <plone:tile /> - to register both of these components in one go. To support creation of appropriate tile links, plone.tiles.data contains two methods - encode() and decode() - to help turn a data dictionary into a query string and turn a request.form dict into a data dict that complies with a tile's schema interface.

plone.transformchain-1.0.3-1.lbn13.noarch

Hook into repoze.zope2 that allows third party packages to register a sequence of hooks that will be allowed to modify the response before it is returned to the browser