Differences

This shows you the differences between two versions of the page.

--- mantisbt:page_template_requirements [2007/05/27 14:48] – comment on per project templates with different fields 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 21: / Line 21: @@
 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 'EXP_TEMPLATE'.
-===== Database Changes =====
+==== Database Changes ====
    * none should be required
-===== Template Construction =====
+==== 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
@@ Line 39: / Line 39: @@
     * Details of template form and construction can be found [[page_template_construction|here]].
-===== File Structure =====
+==== File Structure ====
   |- mantis
       + core
@@ Line 65: / Line 65: @@
       |          +- page.php
-===== Configuration =====
+==== 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 = ''; fields to hide in any view
+==== 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.
 ===== Feedback =====
@@ Line 118: / Line 129: @@
     * Having a theme per project is useful so that administrators can hide fields for different projects.  However, these introduces complexity for the All Projects mode.  Users will be switching from All Projects to a Specific Project causing the theme to change on them.  There will also be the case where the current project is All Projects, but the issue the user is currently viewing belongs to Xyz Project.  I wonder how are we going to handle this complexity.  Are the templates the right approach to show/hide fields per project?  Or should they only be used to do uniform behavior across projects and have some other configuration mechanism to show/hide fields based on the project.  I think if we keep themes and projects independent, then we will have a more flexible and de-coupled approach.  We probably need to include some details about this in the templates design (vboctor).
       * As currently implemented, show/hide of any field is included in the template. That is, you can hide fields per project (as it's read from a config) independently from the template. This feature should be in all templates. (thraxisp)
+        * Having a theme per project may be used for branding.  We have the handle the case where the selected project is All Projects and a bug from a specific project is viewed or being updated (vboctor).
+            * The configuration system may handle this by finding the theme associates with 'ALL_PROJECTS' rather than a specific project on the view_all_bugs page.