This reorganization will be particularly helpful when used in combination with the more advanced Twig functions, and will allow specific components to extend each other, thus reducing the amount of duplicate code, as well as promoting better consistency of said code.
However, in order to do this, we need to change some things in the core. The problem is that most templates (all, except those that are only used via the template
<!-- INCLUDE foobar.html --> command) are hard-coded into the back-end.They are usually assigned using
$template->set_filenames(array('foobar.html' => 'foobar.html'));There are a few problems with this, which are hampering style development:
- All templates are assumed to be in the root
template/directory. This makes it impossible to refactor some template files into subdirectories. - All template names are hard-coded. This prevents us from renaming certain templates, which is useful if we want to split up certain templates (particularly in combination with point 1).
- All template files assume a
.htmlfile extension. Future styles will most likely be written using Twig syntax, rather than our own phpBB template syntax. The preferred file extension for Twig html files is.html.twig.
- Doesn't break backwards-compatibility (or at least doesn’t require major changes to existing 3.1 styles).
- Allows authors a degree of freedom when structuring and naming their templates.
- Allow greater control over the template inheritance tree traversal.
- Is easy to understand.
- Do nothing: this would force all style authors to use the same flat-file structure that we have now, preventing any real style restructuring
- Update all template references in the core: we could update these references to reflect the new template names and directory structure, forcing all new styles to comply (and requiring significant changes to prosilver).
- Have a “template abstraction layer”: each style provides a small file with information that maps the core template references to the actual template files in the style.
Please note that Nicofuma, MichaelC and me have experimented with this implementation. It works, but it is highly experimental code, and very much open for discussion.
Each style would have a
template.json file, which serves only 1 goal: to map the template references in the core to the actual template files in the style. Nothing more.The template engine would be changed to lookup these references in the style to be displayed, instead of the direct filenames. The TAL file would be cached, so lookups are near instantaneous.
This setup differs significantly from "config" files that we had in the past (such as imageset.cfg), in that the TAL doesn't contain any styling information at all, just information on structure.
Code sample:
Code: Select all
{
"faq_body" : "faq.html.twig",
"index_body" : "index.html.twig",
"viewforum_body": "viewforum.html.twig",
"viewtopic_body" : "viewtopic.html.twig",
"mcp_front" : "mcp/index.html.twig",
"ucp_main_front" : "ucp/index.html.twig",
}- Allows style authors complete freedom to structure and name their template files as they see fit.
- Allows for greater inheritance control by allowing the use of namespaces for styles.
- 3.1 compatible styles need only include a single TAL file (which they can simply copy from prosilver 3.2).
- Current styles need to be updated to include the TAL file.
- Support questions for particular styles might become more confusing since template names are variable.
