Skip to content

Commit

Permalink
update
Browse files Browse the repository at this point in the history
  • Loading branch information
jandecaluwe committed Aug 15, 2018
1 parent 0067932 commit 080293b
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 2 deletions.
2 changes: 1 addition & 1 deletion doc/_build/manual/hooks.html
Expand Up @@ -114,7 +114,7 @@ <h2 id="introduction">Introduction</h2>
</tbody>
</table>
<p>You have to make sure that these names are exported correctly. For example, if
you organize <code>_python</code> as a package, it could look as as follows:</p>
you organize <code>_python</code> as a package, it could look as follows:</p>
<div class="codehilite"><pre><span></span>_python/
__init__.py
filters.py
Expand Down
2 changes: 1 addition & 1 deletion doc/_build/tipuesearch/tipuesearch_content.json
Expand Up @@ -188,7 +188,7 @@
},
{
"tags": "",
"text": "Introduction Urubu supports Python hooks to make templating easier. Upon a build, it tries\nto import a _python module or package, and looks for hook variables with\npredefined names. The following hooks are defined: Variable Description filters A mapping from filter names to filter functions. process_info A function to inspect and process content file info. You have to make sure that these names are exported correctly. For example, if\nyou organize _python as a package, it could look as as follows: _python/\n __init__.py\n filters.py\n hooks.py If filters is defined in filters.py , and process_info in hooks.py , the __init__.py file would contain: from .filters import filters\nfrom .hooks import process_info The filters hook Filters functions should be defined as custom filters in\nJinja2 . As a typical example, consider a filter that converts a date value into a\ndesired format. The filters.py module would contain the following: def dateformat(value, format=\"%d-%b-%Y\"):\n return value.strftime(format)\n\nfilters = {}\nfilters['dateformat'] = dateformat You can then use the dateformat filter in templates. The process_info hook The interface of the process_info function is as follows: def process(info, site):\n ... This function is called for every content file in the project. The site variable provides access to the site variables defined in _site.yml . The info variable contains the file content info as it is being\nconstructed by Urubu. At the moment of the call, the following\ninferred attributes are available: Attribute Description id The unique id by which the object is known in the project. url The url of the object. components The components of the object's pathname, without file extension, as a list. fn The pathname of the file or directory corresponding the object. mdate Modification date In addition, all attributes specified in the YAML front matter of the\ncorresponding content file are available as attributes of the info object. The site and info variables are Python dictionaries. This means that the\nattributes are available via key access, not via Python attribute access. This\nis because the YAML reader constructs Python dictionaries from the front\nmatter. The process_info function can can inspect the attributes, verify and modify\nthem, and add additional ones. process_info examples Defining a default layout It can be handy to define a default layout for the case this mandatory\nattribute is not specified in the content file. Suppose we want a default index layout for index files, and a page layout for other files: def process_info(info, site):\n if 'layout' not in info:\n if info['components'][-1] == 'index':\n info['layout'] = 'index'\n else:\n info['layout'] = 'page' Defining a specific layout Suppose we have a blog directory and we want to automatically define a\nspecific post layout for blog posts: def process_info(info, site):\n components = info['components']\n if len(components) == 2:\n if components[0] == 'blog' and components[1] != 'index':\n process_post(info)\n\ndef process_post(info):\n if not 'layout' in info:\n info['layout'] = 'post'",
"text": "Introduction Urubu supports Python hooks to make templating easier. Upon a build, it tries\nto import a _python module or package, and looks for hook variables with\npredefined names. The following hooks are defined: Variable Description filters A mapping from filter names to filter functions. process_info A function to inspect and process content file info. You have to make sure that these names are exported correctly. For example, if\nyou organize _python as a package, it could look as follows: _python/\n __init__.py\n filters.py\n hooks.py If filters is defined in filters.py , and process_info in hooks.py , the __init__.py file would contain: from .filters import filters\nfrom .hooks import process_info The filters hook Filters functions should be defined as custom filters in\nJinja2 . As a typical example, consider a filter that converts a date value into a\ndesired format. The filters.py module would contain the following: def dateformat(value, format=\"%d-%b-%Y\"):\n return value.strftime(format)\n\nfilters = {}\nfilters['dateformat'] = dateformat You can then use the dateformat filter in templates. The process_info hook The interface of the process_info function is as follows: def process(info, site):\n ... This function is called for every content file in the project. The site variable provides access to the site variables defined in _site.yml . The info variable contains the file content info as it is being\nconstructed by Urubu. At the moment of the call, the following\ninferred attributes are available: Attribute Description id The unique id by which the object is known in the project. url The url of the object. components The components of the object's pathname, without file extension, as a list. fn The pathname of the file or directory corresponding the object. mdate Modification date In addition, all attributes specified in the YAML front matter of the\ncorresponding content file are available as attributes of the info object. The site and info variables are Python dictionaries. This means that the\nattributes are available via key access, not via Python attribute access. This\nis because the YAML reader constructs Python dictionaries from the front\nmatter. The process_info function can can inspect the attributes, verify and modify\nthem, and add additional ones. process_info examples Defining a default layout It can be handy to define a default layout for the case this mandatory\nattribute is not specified in the content file. Suppose we want a default index layout for index files, and a page layout for other files: def process_info(info, site):\n if 'layout' not in info:\n if info['components'][-1] == 'index':\n info['layout'] = 'index'\n else:\n info['layout'] = 'page' Defining a specific layout Suppose we have a blog directory and we want to automatically define a\nspecific post layout for blog posts: def process_info(info, site):\n components = info['components']\n if len(components) == 2:\n if components[0] == 'blog' and components[1] != 'index':\n process_post(info)\n\ndef process_post(info):\n if not 'layout' in info:\n info['layout'] = 'post'",
"title": "Python hooks",
"url": "/manual/hooks.html"
},
Expand Down

0 comments on commit 080293b

Please sign in to comment.