mantisbt:page_template_requirements
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
mantisbt:page_template_requirements [2006/09/18 21:54] – created thraxisp | 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. In this case, the display should | + | * 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]]. | ||
+ | |||
+ | ==== 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 ===== | ===== 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 31: | Line 84: | ||
Please add your comments and feedback in this section. | Please add your comments and feedback in this section. | ||
+ | |||
+ | * 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-> | ||
+ | * 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? | ||
+ | * 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. | ||
+ | * Default theme (string) | ||
+ | * Available themes (array) | ||
+ | * Allow users to select theme (boolean). | ||
+ | * 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) | ||
+ | |||
+ | * 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) | ||
+ | * 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) | ||
+ | * notes added (thraxisp) | ||
+ | |||
+ | * 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) | ||
+ | |||
+ | * 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 about 1Mb, trimming it seems to be a good idea. (thraxisp) | ||
+ | |||
+ | * How is this going to affect our installation script? | ||
+ | * 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) | ||
+ | * notes added (thraxisp) | ||
+ | |||
+ | * What will be involved in defining a new theme? | ||
+ | * The admin page that allows you to select themes should traverse the \themes directory so adding a new theme just means putting it in there! (djnz) | ||
+ | * Are we going to do any sort of theme versioning? | ||
+ | * Something that I don't like about applications that use Smarty is that if the web server doesn' | ||
+ | * Yes, this can easily be fixed by checking that the directory is writeable and displaying a friendly non-smarty page if it isn't. (djnz) | ||
+ | * 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) | ||
+ | * 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.1158630864.txt.gz · Last modified: 2008/10/29 04:31 (external edit)