mantisbt:page_template_requirements
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:page_template_requirements [2006/12/12 11:10] – suggestion: empty compile dir on install jotango | mantisbt:page_template_requirements [2011/11/16 07:37] (current) – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol | ||
---|---|---|---|
Line 11: | Line 11: | ||
The general implementation will have the following attributes: | The general implementation will have the following attributes: | ||
* use a generally accepted Template engine - Smarty seems to be a logical choice because of it's widespread adoption and simple implementation. Other engines are probably also viable. | * use a generally accepted Template engine - Smarty seems to be a logical choice because of it's widespread adoption and simple implementation. Other engines are probably also viable. | ||
- | * have different selectable views for the same site - different themes should be available. When a specific template is missing, the display should fall back to a default template. | + | * have different selectable views for the same site - different themes should be available. When a specific template is missing, the display should fall back to a default template. Users should be able to select a template for their viewing. Administrators should also be able to restrict the templates that are available to users. It should also be possible to select different default templates for each project. |
* Within a theme, it should be trivial to remove a field from the display. | * Within a theme, it should be trivial to remove a field from the display. | ||
* an individual user should be able to select their theme for the site, or an specific project | * an individual user should be able to select their theme for the site, or an specific project | ||
* the existing multi-lingual interface is required. Retaining the existing language files is desired. | * the existing multi-lingual interface is required. Retaining the existing language files is desired. | ||
- | ===== Database Changes | + | ===== Implementation Notes ===== |
+ | The implementation consists primarily of removing display statements from the existing code. This work is significant as much of the code embeds the display function at lower levels. | ||
- | * none should | + | Development of this feature will be done on a branch from the 1.1 stream. This will allow normal development to proceed while the core is reworked. The code will eventually be folded back into the main stream. The branch is labelled ' |
- | ===== Template Construction ===== | + | ==== Database Changes |
- | | + | * none should be required |
+ | |||
+ | ==== Template Construction ==== | ||
+ | * templates will be created to split up the functionality on the pages to reasonable size parts. In general, common sections will be placed into separate files. For example, the template for the bug page will be split up as follows: | ||
+ | * page header | ||
+ | * login information and project selector | ||
+ | * top menu | ||
+ | * bug description | ||
+ | * action menu | ||
+ | * ... | ||
+ | * bug notes | ||
+ | * page footer | ||
+ | | ||
* bugs and other information will be passed through an instance of the " | * bugs and other information will be passed through an instance of the " | ||
+ | * Details of template form and construction can be found [[page_template_construction|here]]. | ||
- | ===== Other Changes ===== | + | ==== File Structure |
+ | |- mantis | ||
+ | + core | ||
+ | | +- smarty (smarty dir, changeable) | ||
+ | + languages | ||
+ | | +- eng | ||
+ | | +- etc.... | ||
+ | + themes | ||
+ | | +- theme1 | ||
+ | | +- header.tpl | ||
+ | | +- footer.tpl | ||
+ | | +- page.tpl | ||
+ | | +- images | ||
+ | | +- image.png | ||
+ | | +- css | ||
+ | | +- mantis.css | ||
+ | | +- theme2 | ||
+ | | +- page.tpl | ||
+ | + themes_c | ||
+ | | +- theme1 | ||
+ | | +- header.php | ||
+ | | +- footer.php | ||
+ | | +- page.php | ||
+ | | +- theme2 | ||
+ | | +- page.php | ||
+ | ==== Configuration ==== | ||
+ | * $g_c_template_path - path to writable compiled templates directory | ||
+ | * $g_theme_default - default theme to use | ||
+ | * $g_theme_override - override theme to use (usually set in a project or user) | ||
+ | * $g_hide_fields = ''; | ||
+ | |||
+ | ==== Implementation Log ==== | ||
+ | * [[page template todo|To Do List / Log]] | ||
+ | |||
+ | |||
+ | ===== Other Changes ===== | ||
+ | * The installer needs to be updated to create and check that the appropriate directories have been created. Note that the compiled templates need to be erased if the source files change. | ||
Line 37: | Line 87: | ||
* How about introducing a standard where all parameters prepared and sent to the templates are prefixed with " | * How about introducing a standard where all parameters prepared and sent to the templates are prefixed with " | ||
* That would be a good idea. Note that for various reasons it is most efficient to pass variables to templates in arrays (or objects). So you would have a template to display bugs in a table. The code calling this template would assemble the data for the bugs into the array $tpl_bugs and then do $smarty-> | * That would be a good idea. Note that for various reasons it is most efficient to pass variables to templates in arrays (or objects). So you would have a template to display bugs in a table. The code calling this template would assemble the data for the bugs into the array $tpl_bugs and then do $smarty-> | ||
+ | * Agreed. Most bug related data should pass through objects. This allows some database lookups to be deferred when displaying the bug. (thraxisp) | ||
+ | |||
* When a template is found, do we only default to one templates? | * When a template is found, do we only default to one templates? | ||
* This functionality (theme overloading) is built into Smarty - just set $smarty-> | * This functionality (theme overloading) is built into Smarty - just set $smarty-> | ||
+ | * I will use the facilities in Smarty for this (thraxisp) | ||
+ | |||
* We need to specify the configuration variables that will be added. | * We need to specify the configuration variables that will be added. | ||
* Default theme (string) | * Default theme (string) | ||
Line 45: | Line 99: | ||
* Is there an advantage in making the path to the themes and themes_c folders configurable? | * Is there an advantage in making the path to the themes and themes_c folders configurable? | ||
* themes_c (if you want to call it that) should be configurable to allow users to move it outside the web root. (djnz) | * themes_c (if you want to call it that) should be configurable to allow users to move it outside the web root. (djnz) | ||
+ | |||
* Specify the structure of the themes folder. | * Specify the structure of the themes folder. | ||
* I would recommend that each theme has all its templates in a \templates directory, with a separate directory for \images (djnz) | * I would recommend that each theme has all its templates in a \templates directory, with a separate directory for \images (djnz) | ||
+ | * notes added (thraxisp) | ||
+ | |||
* It is probably worth clarifying the impact of using templates on the current code base. Other than the PHP web pages, this will also have a major impact on our print_* and html_* APIs. We need to separate the data preparation from the outputing of html. Most of the functionality in print_api.php should be refactored and moved into prepare_api.php or other APIs. (vboctor) | * It is probably worth clarifying the impact of using templates on the current code base. Other than the PHP web pages, this will also have a major impact on our print_* and html_* APIs. We need to separate the data preparation from the outputing of html. Most of the functionality in print_api.php should be refactored and moved into prepare_api.php or other APIs. (vboctor) | ||
+ | * notes added (thraxisp) | ||
+ | |||
* Are we going to make use of Smarty functions and modifiers? | * Are we going to make use of Smarty functions and modifiers? | ||
* This would be a very good use for a Smarty modifier. It could also be made themeable. (djnz) | * This would be a very good use for a Smarty modifier. It could also be made themeable. (djnz) | ||
+ | |||
* It is probably worth specifying that we will distribute Smarty with Mantis and that it will be located under core/ | * It is probably worth specifying that we will distribute Smarty with Mantis and that it will be located under core/ | ||
* Smarty is smaller than ADODB. Having said that, we probably don't want the demo applications. (djnz) | * Smarty is smaller than ADODB. Having said that, we probably don't want the demo applications. (djnz) | ||
+ | * SMARTY is about 1Mb, trimming it seems to be a good idea. (thraxisp) | ||
+ | |||
* How is this going to affect our installation script? | * How is this going to affect our installation script? | ||
* You need to check that themes_c is writeable, that is all. (djnz) | * You need to check that themes_c is writeable, that is all. (djnz) | ||
* I would suggest emptying the themes_c directory during install. Smarty has some problems with recognizing changed templates. Emptying the compile directory removes this problem (jotango) | * I would suggest emptying the themes_c directory during install. Smarty has some problems with recognizing changed templates. Emptying the compile directory removes this problem (jotango) | ||
+ | * notes added (thraxisp) | ||
* What will be involved in defining a new theme? | * What will be involved in defining a new theme? | ||
Line 63: | Line 126: | ||
* Does Smarty support a mode where the compiled templates can be saved to the database rather than as files? (vboctor). | * Does Smarty support a mode where the compiled templates can be saved to the database rather than as files? (vboctor). | ||
* This would be a bad idea. Smarty compiles templates into PHP so that they run quickly, getting the benefit of any PHP accelerator you are running, or at least PHP's tokenizer. If you retrieved the compiled PHP from the database how would you execute it? (djnz) | * This would be a bad idea. Smarty compiles templates into PHP so that they run quickly, getting the benefit of any PHP accelerator you are running, or at least PHP's tokenizer. If you retrieved the compiled PHP from the database how would you execute it? (djnz) | ||
+ | * I agree with djnz. Why would this be useful? (thraxisp) | ||
+ | * Having a theme per project is useful so that administrators can hide fields for different projects. | ||
+ | * As currently implemented, | ||
+ | * Having a theme per project may be used for branding. | ||
+ | * The configuration system may handle this by finding the theme associates with ' | ||
+ |
mantisbt/page_template_requirements.1165939836.txt.gz · Last modified: 2008/10/29 04:31 (external edit)