Provide parts of a web application as tiles.
Tiles for use in pyramid framework
This package provides rendering snippets of markup organized as tiles for the pyramid framework.
A tile is a piece of web application, i.e. a form, a navigation, etc.
Splitting your application in such small and logic application parts makes it easy to re-use this application, simplifies application AJAXification and the use of same application parts in different manners.
A tile is registered similar to a pyramid view. Registration is done with the cone.tile.registerTile function:
>>> from cone.tile import registerTile >>> registerTile('a_tile', ... 'package:browser/templates/a_tile.pt', ... permission='view')
or the cone.tile.tile decorator on classes:
>>> from cone.tile import tile, Tile >>> @tile('b_tile', 'package:browser/templates/b_tile.pt', ... permission='view', strict=False) ... class BTile(Tile): ... pass
Both, decorator and register function accept following arguments:
- Identifier of the tile (for later lookup).
- Either relative path to the template or absolute path or path prefixed by the absolute package name delimeted by ‘:’. If path is used attribute is ignored.
- Attribute on the given _class to be used to render the tile. Defaults to render.
- Interface or class of the pyramid model the tile is registered for.
- Class to be used to render the tile. usally cone.tile.Tile or a subclass of. Promises to implement cone.tile.ITile. When the tile decorator is used, the decorated class is expected as tile implementation.
- Enables security checking for this tile. Defaults to view. If set to None security checks are disabled.
- Wether to raise Forbidden or not if rendering is not permitted. Defaults to True. If set to False the exception is consumed and an empty unicode string is returned.
Tiles can be overwritten later while application initialization by just registering it again. This is useful for application theming and customization.
Tile rendering with the render_tile function:
>>> from cone.tile import render_tile >>> rendered = render_tile(model, request, name)
Inside templates which are bound to the tile, more tiles can be rendered on current model and request via tile:
>>> <tal:sometile replace="structure tile('tilename')"
A tile is similar to what’s known in the zope world as content provider.
Before rendering of the tile is done, the prepare function is called which can be used to load data or whatever.
Further, the show flag is considered (which might have been set in the prepare function) and rendering is skipped if it evaluates to False.
More on rendering
There are helper functions for rendering which pass the tile renderer to templates for invoking child tiles and consider redirections.
The tile class provides a redirect function, which expects either a string containing a URL or a webob.exc.HTTPFound instance. This causes rendering of remaining tiles to be skipped and request.environ['redirect'] to be set.
- Render template. Passes tile renderer to template. Considers redirection. Returns empty string if redirection found.
- Render template to response. Passes tile renderer to template. Considers redirection. Returns HTTPFound instance if redirection found, otherwise rendered response.
- Renders some result to the response considering redirection. Returns HTTPFound instance if redirection found, otherwise rendered response.
Summary of the test coverage report:
lines cov% module 1 100% cone.tile.__init__ 193 100% cone.tile._api 12 100% cone.tile.tests
- Robert Niederreiter <rnix [at] squarewave [dot] at>
- Jens Klein <jens [at] bluedynamics [dot] com>
- Attila Olah
- Use traceback module instead of zope.exceptions to format exceptions in render_template. [rnix, 2017-10-06]
- Remove log_exception utility and use registered IDebugLogger in cone.tile._api.render_template for exception logging. [rnix, 2017-03-24]
- Tile registration name is taken from Tile subclass if not given in registerTile function and tile decorator. [rnix, 2017-02-17]
- name is now optional in registerTile function and tile decorator. [rnix, 2017-02-17]
- Default attribute is now None in registerTile function and tile decorator to ensure considering attribute from Tile subclass if set. [rnix, 2017-02-17]
- Tile.name, Tile.path and Tile.attribute can be set on Tile subclass directly without being overwritten at tile registration if not given. [rnix, 2017-02-17]
- Errors caught in render_tile may contain umlaute. Properly decode error string. [rnix, 2017-02-13]
- Using and depending now on zope.exceptions to format tracebacks with supplements. [jensens, 2012-06-06]
- Improved visibility of tracebacks, they appear now in the error log. even if an expression like `tal:replace="structure tile('editform')"` ate it, the traceback is logged. traceback supplements are rendered. [jensens, 2012-06-05]
- Removed superfluos try except [jensens, 2012-06-05]
- Fixed dependencies for integrated tests [jensens, 2012-06-05]
- Tiles can be overwritten. [rnix, 2012-05-22]
- Use zope.interface.implementer instead of zope.interface.implements. [rnix, 2012-05-18]
- Fit for pyramid 1.1 + 1.2 [rnix, 2011-09-08]
- Documentation [rnix, 2011-09-08]
- Make it work [jensens, rnix, et. al]
Copyright (c) 2009-2017, BlueDynamics Alliance, Austria All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- Neither the name of the BlueDynamics Alliance nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY BlueDynamics Alliance AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BlueDynamics Alliance BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.