Changes between Version 7 and Version 8 of TracLegosTemplates

Timestamp:

Nov 2, 2015, 10:33:35 AM (8 years ago)

Author:

figaro

Comment:

Tagged as reference

TracLegosTemplates

@@ -1 +1 @@
 = [TracLegosScript TracLegos] Templates =
 
-[TracLegosScript TracLegos] is designed to be a templating engine for Trac projects.  More than one template can be specified in which case the templates are applied in order -- that is, latter templates override `trac.ini` values from earlier templates.
+[TracLegosScript TracLegos] is designed to be a templating engine for Trac projects. More than one template can be specified in which case the templates are applied in order. That is, latter templates override `trac.ini` values from earlier templates.
 
 [[Image(source:traclegosscript/anyrelease/image/template_aggregation.png)]]
 
-The image shows an example of the application of three templates to create a Trac project.  The first template applied, [source:traclegosscript/anyrelease/example/oss/osstracproject/template/conf/trac.ini_tmpl OSS Trac Project], is a skeleton for a trac project.  The second template is a (''hypothetical'') template that applies configuration for `Plugin 'A'`.  This illustrates the value of allowing arbitrary configuration -- a template can be as specific or as general as needed (that is, any portion of the `trac.ini` may be contained in the template).  Both of these templates are generic -- they contain configuration that is agnostic to a specific site or organization.  This generic configuration is augmented by the `Site Configuration`, which contains parameters specific to the site and organization.  Any number of these can be applied.
+The image shows an example of the application of three templates to create a Trac project. The first template applied, [source:traclegosscript/anyrelease/example/oss/osstracproject/template/conf/trac.ini_tmpl OSS Trac Project], is a skeleton for a trac project. 
 
-The templates are implied in order, values from latter templates overwriting earlier ones.  From the aggregated configuration, a trac project is made using supplied variables.
+The second template is a (''hypothetical'') template that applies configuration for `Plugin 'A'`. This illustrates the value of allowing arbitrary configuration -- a template can be as specific or as general as needed (that is, any portion of the `trac.ini` may be contained in the template). Both of these templates are generic -- they contain configuration that is agnostic to a specific site or organization. This generic configuration is augmented by the `Site Configuration`, which contains parameters specific to the site and organization. Any number of these can be applied.
+
+The templates are implied in order, values from latter templates overwriting earlier ones. From the aggregated configuration, a Trac project is made using supplied variables.
 
 == Convention-based Variables ==
 
-With a few exceptions (e.g. `project`), [TracLegosScript TracLegos] does no sort of enforcing of similarity of template parameters.  [TracLegosScript TracLegos] asserts a convention-based system where template authors are encouraged to use a convention that works with them and the world at large.  For example, the [source:traclegosscript/anyrelease/example/oss/osstracproject/template/conf/trac.ini_tmpl OSS Trac project template] uses a variable, `$basedir`, that defines a base directory relative to which it defines by convention several file locations.  If this pattern fits the use case for a new template, keeping the variable name intact allows site configuration and other locations addressing variables by name to work as expected whereas renaming the variable would require more work to incorporate it into existing instances.  However, if this convention did not work for your template, then you should use a convention that does, preferably with a variable name that is unambiguous.  [TracLegosScript TracLegos] uses a flat namespace for simplicity and is not slated to move towards namespacing variables.
+With a few exceptions (e.g. `project`), [TracLegosScript TracLegos] does no sort of enforcing of similarity of template parameters. [TracLegosScript TracLegos] asserts a convention-based system where template authors are encouraged to use a convention that works with them and the world at large. For example, the [source:traclegosscript/anyrelease/example/oss/osstracproject/template/conf/trac.ini_tmpl OSS Trac project template] uses a variable, `$basedir`, that defines a base directory relative to which it defines by convention several file locations. If this pattern fits the use case for a new template, keeping the variable name intact allows site configuration and other locations addressing variables by name to work as expected whereas renaming the variable would require more work to incorporate it into existing instances. However, if this convention did not work for your template, then you should use a convention that does, preferably with a variable name that is unambiguous. [TracLegosScript TracLegos] uses a flat namespace for simplicity and is not slated to move towards namespacing variables.