Gossamer Forum
Home : Gossamer Threads Inc. : Discussion :

[Suggestion] New GT template system

Quote Reply
[Suggestion] New GT template system
Important note: The suggested new template system would be completely backward compatible with the GT template used in v2.x GT products! Nobody would need to use the new skeleton based template system if doesn't want.


I decided to start a new thread about my suggested new GT template system.
The template discussion started in this thread:
Gossamer Links 3.0 mockup

I suggested:
Quote:
It would be really important to improve the template system, to support skeleton-like, "sites-themes-elements" style, which can inherit content from parent content. All this, to ignore redundant HTML codes.

Avoiding redundant HTML codes, and skeleton based inheriting would be important part of the new template system.

Imagine, that you want to change the whole lookout, the design of your site, and you need to change the main table structure just in one file, and not in all 30-50-100 template files you use. Do you see how much time (and time is money) could you save with this new template system? Not to mention the advantage, that you can change your site design within days (and not within weeks), which can give you the possibility to upgrade your site design as often you need, to keep yourself competitive with your competitors.


I extended the template system idea a bit to be a 4 level hierarhical template system:
Site-Theme-Page-Element + Styles template system
The 5. Style is not really a hierarchical element, as any hierarchical level may contain styles. The style could be also skeleton based, inherited if needed. That's why it's mentioned separately. I'm not style expert so comments are welcome about style implementation.


Site: site is new concept. contains the whole site skeleton, theme skeleton, pages, elements, styles.
Theme: (currently known as template set) contains theme skeleton, pages, elements, styles
Page: (currently known as template) contains pages, elements, styles
Element: (currently known as includes, but would group more than includes) contains elements, styles
Styles: contains styles only. Style is not really a hierarchical element, as any hierarchical level may contain styles. But style could be also skeleton based, inherited if needed. I'm not style expert so comments are welcome about style implementation.


Details are described following posts.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Last edited by:

webmaster33: Mar 23, 2005, 1:56 AM
Quote Reply
Re: [webmaster33] [Suggestion] New GT template system In reply to
The new template concept needs to modify some terms:
Site = new term, means the whole site. Wraps its Themes in a Site directory
Theme = template set (directories below the Site directory)
Page = template (may still use the template term, but Page is more clear)
Element = all contents, which are included, used, reused in Pages

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] [Suggestion] New GT template system In reply to
The first problem in the GT template system, that GT template is using FLAT template set.
FLAT means, that each page must contain the whole design structure, from header to tables. This makes design changes incredibly difficult, as you need to do each design change on all your 50-100 used template pages...

Using my suggestions you can keep compatibility with old template sets, while adding features like inheritance, directories, template variable files, template set config variables.
Skeleton inheritance and directory features may cause a little speed decrease for new kind templates, but instead you get an easier modifiable template system, where you can do 1 change, that will affect all your sites, cobranded sites, or just a content part. Skeleton based inheritance will make our life easier...
Note, GT apps already have inheritance implemented, so skeleton inheritance is just a further step toward easier template modifications.

There will be not forced to use skeleton inheritance or directories (you can turn off these features), but those who want to make their life easier, will have the ability to use these features.

  1. Directories: You should add the vertical thinking into GT template system.
    • I mean, there should be directories available in each Theme (template set), which inherits content from default Pages (templates).

    • Grouping: Directories will help us to group the site content easier. E.g. with directories contents, menus, javascripts, css, etc.

    • There will be only 3 special directories: _config, _compiled and _local directories.

    • The _config is the only new type, and will contain config file(s) which will control the template features, and the inheritance.

    • There is a global Default Theme (template set), from where everything else sites & themes are inheriting the missing files.

    • The Site directories are placed near the global Default Theme (template set), as mysite.com or partnersite.com, etc... The site is identified as 's=mysite.com' or 'site=mysite.com' in the URLs. If no site is set in the URL, then the default site will be used which is set in the config.
      Note, each Site needs to have a default Theme (template set). The currently used build_default_tpl inconfig, should be changed to build_default_site. The build_default_tpl would be still exist internally, but not on the admin interface, as build_default_tpl is site dependent, so each Site may have different default Theme.

    • The Theme directories are placed under the mysite.com, partnersite.com Site directories... Themes are identified as 't=mytheme' in the URLs.

    • The Pages or Elements are not reflected in the URLs in any way, they are used internally only (same as current way).

    • Since the Site directory is a new directory inserted above Theme directory, we need to distinguish v2.x template directories from the skeleton templates. For backward compatibility, the v2.x templates are used by default. This is set in config, but can change which to be the default.
      The skeleton based template directories are distinguished by the 'version' variable used in .tplinfo config file.


    Example directory structure:
    template set main folder is: /cgi-bin/gt/templates/
    template sets are:
    /cgi-bin/gt/templates/admin/
    /cgi-bin/gt/templates/default/
    /cgi-bin/gt/templates/mysite.com/default/
    /cgi-bin/gt/templates/mysite.com/mytheme/
    /cgi-bin/gt/templates/mysite.com/light/
    /cgi-bin/gt/templates/mysite.com/dark_theme/
    /cgi-bin/gt/templates/mysite.com/nojava/
    /cgi-bin/gt/templates/mysite.com/framed/
    /cgi-bin/gt/templates/mypartnersite.com/default/
    /cgi-bin/gt/templates/othersite.com/default/

    within themes, futher directories can be used for grouping (example for Links SQL):
    /cgi-bin/gt/templates/mysite.com/mytheme/includes/
    /cgi-bin/gt/templates/mysite.com/mytheme/css/
    /cgi-bin/gt/templates/mysite.com/mytheme/browser/
    /cgi-bin/gt/templates/mysite.com/mytheme/review/
    /cgi-bin/gt/templates/mysite.com/mytheme/email/
    /cgi-bin/gt/templates/mysite.com/mytheme/search/
    /cgi-bin/gt/templates/mysite.com/mytheme/payment/
    finally only a few (but the most important) pages, are remaining in theme root, like home.html, category.html, new.html, etc... This highly increases the usability, when using text/HTML editors and file managers.



  2. Inheritance:
    • As mentioned by GT staff, this feature is already available in GT v2.x apps, and multiple template interitance is possible in GT v3.x apps. However template interitance may be need to be modified a bit, to treat the new sketeon inheritance feature.

    • There will be a global Site folder, named "default", which gaves us the skeleton of our Site lookouts, and partner's sites can inherit from our default site lookout if needed.

    • Content of this "default" Site is inherited in each Site (template set), where a file is used (except, if it is turned off in in global config, turned off in default template set, or turned off in config of target tempate set).

    • There will be possible to turn on/off the template inheritance using template config variables (explained later).

      Example:
      <%include /mypartnersite.com/mytheme/menu/content.html%>
      • A file is included from "mypartnersite.com" Site, "default" Theme, "menu" dir.

      • The search & inheritance path should be the following, if the /mypartnersite.com/mytheme/menu/content.html file is missing:
        1) /mypartnersite.com/mytheme/content.html
        2) /mypartnersite.com/default/menu/content.html
        3) /mypartnersite.com/default/content.html
        4) /default/mytheme/menu/content.html
        5) /default/mytheme/content.html
        6) /default/default/menu/content.html
        7) /default/default/content.html
        8) /default/content.html
        A debug level 2 warning should be noted for each case, when the file was not found in any of paths above.

      • If /cgi-bin/gt/templates/default/content.html is also missing, then a fatal error or a "template not found" message is displayed, based on config options. The fatal debug error shows: "content.html is missing".



  3. Site & Theme config:
    • Each Theme (template set) will have a config.

    • Config file will be placed into "_config" dir, within Site dir or Theme dir.

    • Config file is named ".tplinfo".

    • Search & inheritance path of config file:
      If /cgi-bin/gt/templates/mypartnersite.com/mytheme/_config/.tplinfo config file is missing,
      search & inheritance path will be the following:
      1) /cgi-bin/gt/templates/mypartnersite.com/mytheme/_config/.tplinfo
      2) /cgi-bin/gt/templates/mypartnersite.com/_config/.tplinfo
      3) /cgi-bin/gt/templates/mypartnersite.com/default/_config/.tplinfo
      4) /cgi-bin/gt/templates/default/mytheme/_config/.tplinfo
      5) /cgi-bin/gt/templates/default/default/_config/.tplinfo
      6) /cgi-bin/gt/templates/default/_config/.tplinfo

    • If config file is missing from 6 level, too, then Site & Theme related config values are inherited from a global admin config.

    • 'template_system_version' variable: stores GT template system version for backward compatibility. From v3.5 skeleton template system is allowed. Below, the old compatibility template rules are used.[/i]

    • 'disabled' variable: allows to disabled a Site or Theme in the config file. In this case, Default Site or Theme will be displayed. Optionally may be possible to display a message: "This Site/Theme was disabled. Contact admin for more info."

    • 'inheritance' variable: shows path from where Site or Theme is inherited.

    • 'inheritance_allowed' variable: allow inheritance. If disabled, the path inheritance walktrough will be not done, a fatal error or a "template not found" message is displayed immediately, based on config options. The fatal debug error shows: "content.html is missing".

    • 'variable_files_allowed' variable: allows to search for variable files. By default this is turned off in admin config for performance reasons.

    • 'globals_variable_inherit_allowed' variable: we sets which globals to be allowed to be inherited, and which not.
      For security reasons, we should have full control over which globals we allow to inherit, and which not. In global admin config we should have a variable, where we are listing, which Sites or Themes are allowed to inherit, which global variables.
      Keys can be 'Site' or 'Site/Theme'. Values can be 1 or 0 or array.
      1 allows full global inheritance, 0 denies global inheritance, array lists the allowed globals inheritance.


      Example:
      The .tplinfo config file may be placed into Site/_config/ dir or Theme/_config/ dir:
      /cgi-bin/gt/templates/mypartnersite.com/mytheme/_config/.tplinfo
      or
      /cgi-bin/gt/templates/mypartnersite.com/_config/.tplinfo
      Code:
      {
      # GT template system version for backward compatibility.
      #From GT template version v3.5, the skeleton template system is allowed

      'template_system_version' => '3.5',

      # disabled: used for quickly disabling a Site or Theme (template set).
      # Default Site or Theme will be displayed, if disabled.

      'disabled' => 1,

      # inherit_from_theme: name of theme we are inherit from.
      # if missing, "default" template set is used
      'inheritance' => '../../../mysite.com/mytheme',

      # inheritance_allowed:
      # allows to inherit templates from Sites & Themes

      'inheritance_allowed' => 1,

      # variable_files_allowed: allows to use variable files in Site or Theme
      'variable_files_allowed' => 1

      # globals_variable_inherit_allowed:
      # this sets which globals to be allowed to inherit, and which not

      'globals_variable_inherit_allowed' => {
      # we allow full globals inheritance of default Site
      'default' => 1,
      # we allow full globals inheritance of just mysite.com/mytheme Theme
      'mysite.com/mytheme' => 1,
      # array means the list of globals allowed to inherit
      # we allow limited globals inheritance for full other_cobrandsite.com Site
      'other_cobrandsite.com' => [ 'cobrand_text', 'date', 'time' ],
      # we allow limited globals inheritance just for mysite.com/mytheme Theme
      'mypartnersite.com/mytheme' => [ 'cobrand_text', 'date', 'time', 'list_categories' ],
      # we fully deny globals inheritance for simple_partner.com Site & Themes
      'simple_partner.com' => 0,
      }

      };

    • The globals.txt and language.txt should be also placed into "_config" directory.
      /cgi-bin/gt/templates/mypartnersite/_config/globals.txt
      /cgi-bin/gt/templates/mypartnersite/_config/language.txt
      Search & inheritance path of globals.txt and language.txt files:
      If /cgi-bin/gt/templates/mypartnersite.com/mytheme/_config/.tplinfo config file is missing,
      search & inheritance path will be the following:
      1) /cgi-bin/gt/templates/mypartnersite.com/mytheme/_config/
      2) /cgi-bin/gt/templates/mypartnersite.com/_config/
      3) /cgi-bin/gt/templates/mypartnersite.com/default/_config/
      4) /cgi-bin/gt/templates/default/mytheme/_config/
      5) /cgi-bin/gt/templates/default/default/_config/
      6) /cgi-bin/gt/templates/default/_config/
      A debug level 2 warning should be noted for each case, when the file was not found in any of paths above.

    • if globals.txt or language.txt is missing from 6. level, too, then fatal debug error will happen: "globals.txt or language.txt is missing".



  4. Variable files: Also variable files needed to be implemented.
    • These variable files have the same filename like the one we inherit, but will have .var extension. Variable files should be placed into the template set or inside a directory, where we want to change an inherited content.

    • inherited content change can be done through these .var files, simply by setting template tags.

    • Variable files are such templates, where additional template tag changes are done, without the need to duplicate the whole template file.
      For example no need duplicate the full home.html template Page, we just set a small home.var, where we override for example the <%site_title%> tag, using <%set site_title = 'The new site title'%>.
      This way we avoided HTML duplication, and reused all possible codes by 100%.

    • If we want to change <%site_title%> tag in home.html with global, we don't need home.var file, as we can add the global directly into
      /mypartnersite.com/_config/global.txt for Site level global
      or
      /mypartnersite.com/mytheme/_config/global.txt for Theme level global

    • Using Theme level globals, you can override Site level globals (might be better to call these ones as Site locals or Theme locals)

    • home.var will affect home.* templates (like home.html, home.htm, home.tpl, etc...), which are inherited from Site or Theme set by config file

    • New variables: Some new variables should be used like: $source_path, $source_site, $source_theme, etc...
      $source_site: the Site directory name, from where we inherited this template: = "mypartner.com" or "default" or ""
      $source_theme: the Theme directory name, from where we inherited this template: = "mytheme" or "default" or ""
      $source_filename: the filename from where we inherited this Page template: = "content.html"
      $source_dir: the dirname (within Site/Theme directories, which is used to group templates), from where we inherited this template. "dirname" or ""
      $source_path: the path from where we inherited this template: = /$source_site/$source_theme/$source_dir
      $source_filepath: the filepath from where we inherited this template: = /$source_site/$source_theme/$source_dir/$source_filename

      $current_site: the Site directory name, we are currently in: = "mypartner.com"
      $current_theme: the Theme directory name, we are currently in: = "mytheme"
      $current_filename: the filename of this template: = "content.html"
      $current_dir: the dirname, where we currently are: = "sidebar"
      $current_path: the path we currently are: = /$current_site/$current_theme/$current_dir
      $current_filepath: the path we currently are: = /$current_site/$current_theme/$current_dir/$current_filename

    • Security warning: include should DENY usage of path, which is not beginning with $inherited_path path (espedially those which are pointing out outside of the template root, and those matching =~ /\.\.\//)! Also should DENY $inherited_path/_compiled, $inherited_path/_config paths.


    Content of home.html in "default" template set:
    Code:
    <html>
    <head>
    <title><%site_title%>: <%page_title%></title>
    <%include $current_path/include_common_head.html%>
    </head>
    <body id="<%page_id%>">
    <%include $current_path/include_header.html%>
    ...
    <%include $current_path/$sidebar_template%>
    ...
    <%include $current_path/$content_template%>
    ...
    <%include $current_path/$menu_right_template%>
    ...
    <%include $current_path/include_footer.html%>
    </body>
    </html>

    Of course, we could copy home.html into the "mypartner.com" Site template, but since we want the same skeleton into "mypartner.com" Site template like the one from "default", we can just ignore this file, leaving the template system to inherit it from "default", and use the home.var file in "mypartner.com", to set the variable contents.
    If the "sidebar_template" would be the same, we could just ignore it (since we don't want to duplicate it), so we can leave the template system to inherit it from the "default" set.
    I think we always wanted something like this...


    So in home.var in "mypartner.com" template set:
    Code:
    <%set page_title = "my page title"%>
    <%set page_id = "my_page"%>
    <%-- set sidebar_template = "sidebar.html" --%> => commented out, to be inherited
    <%set content_template = "content.html"%>
    <%set menu_right_template = "
    <a href="/menu_right_1.html">Menu right 1</a>
    <a href="/menu_right_2.html">Menu right 2</a>
    <a href="/menu_right_3.html">Menu right 3</a>
    "%>

    BTW: is multiline <%set ...%> template command working as used in example above?
    Or it is working only in single line?

    Personally I would better welcome a variable file, which can be divided into several clean content parts.
    I mean home.var in "mypartner.com" Site template, might be better to look like this:
    Code:
    [page_title]
    my page

    [page_id]
    my_page

    [sidebar_template]
    sidebar.html

    [content_template]
    content.html

    [menu_right_template]
    <a href="/menu_right_1.html">Menu right 1</a>
    <a href="/menu_right_2.html">Menu right 2</a>
    <a href="/menu_right_3.html">Menu right 3</a>
    (maybe closing tags, like [/menu_template] may be also used, if needed, but I think this is unnecessary)
    Well, I see the parsing problems of this kind of template, so I don't force it anyway.



Now to answer some GT worries:
Quote:
  • It would at least triple the template count (from 57 to 150+) - it's already pretty confusing as is. With other programs like Gossamer Mail, we're talking about going from 88 templates to over 250!
  • The directory grouping feature will solve this problem. The result template set is, grouped by directories is easily understandable. Result template set is not confusing, IMO, no matter how many templates is used (if grouped correctly into dirs).
    I believe, even thousands of files could be clearly grouped this way, without being confusing for the template editor.


    Quote:
  • It makes understanding the templates a little more complicated - opening the page template and only seeing some set's and an include is pretty strange.
  • Understanding the templates is not difficulter. Especially when looked at cloned templates.
    I believe, if we split the skeleton ("the bones"), from "the meal", the result is a more solid template system, where we have the often changed elements separated from the standard elements.
    This is similar to how we are separating the source code from the content.


    Quote:
  • It's not very flexible. If a page needs to load some javascript, without putting a whole bunch of extra <%if foo%><%include $foo%><%endif%>'s in the site template, you won't be able to load the javascript in the head.
  • We can load several javascripts into the default using <%include $current_path/js/javascripts.js%>.
    We can implement a template set option, not to display include errors on the page, but to redirect them as debug messages, instead.

    If that's not enough, an optional "if item" for include command may be implemented.
    Examples:
    <%include $foo if $variable = "something"%> - include based on expression result
    <%include $foo if $variable%> - include based on existance checking of another variable
    <%include $foo if%> - include based on existance checking of currently used $foo variable
    <%$foo if%> - condifional checking of currently used $foo variable. This requires closing tag: <%endif%>
    The ideas are taken directly from Perl syntax, so these examples are not a strange at all.

    The implementation could be, like:
    <%[command] $variable if [expression]>

    The short one would look like this:
    <%include $foo if>
    instead of the currently used long one:
    <%if foo%><%include $foo%><%endif%>
    The <%include $foo if> would simplify many-many if conditions, while keeping the template clear & understandable.
    Note, that you can still use the old, long condition anytime, if you want...
    Backward compatibility is kept anyway!


    Quote:
  • The site_templates will appear to be broken html to any html editors
  • Since my the skeleton itself is not broken into several part in my suggested solution, the html editors will show up correctly, highlight correctly. I use UltraEdit as HTML editor, so this is also important for me.


    Quote:
  • It is also not flexible
  • I think this suggested solution is flexible as much as possible.
    But I'm open to discuss the problems, if there are any.


    Quote:
  • The page templates just don't look that nice :)
  • Since the often changed (variable content) parts, are separated from the rarely changed skeleton parts, it looks better, modification should be easier. And while the file count is increased, the clean directory structures can help work of template editors.



    I believe, if this kind of GT template system improvements would be implemented into next GT products version. They will make GT products (especially GT Links SQL, GForum, GT DBMan SQL) unbeatable.
    The ease & speed of design upgrades will make GT products a preferred choice over similar systems.
    Site owners using GT products, will be able to improve their site easier, faster, cheaper, thus more often.
    And we all know from internet marketing: faster (or cheaper) site developments is one of the tools, which can increase market share of our site, service.



    Nothing guarantees, that my ideas are the best.
    I just try to express those needs, which are awaited by me, and supposedly meet needs of other
    web developers, too.
    If anybody has better idea, or solution, I would really welcome it.

    Waiting your comments, ideas...

    Best regards,
    Webmaster33


    Paid Support
    from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
    Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
    Quote Reply
    Re: [webmaster33] [Suggestion] New GT template system In reply to
    I just checked the Template Toolkit template system, and it seems it knows all the features, I listed above and much more.
    http://www.template-toolkit.org/...tax.html#DESCRIPTION
    http://www.template-toolkit.org/...n/Modules/index.html
    http://www.template-toolkit.org/...in/Tutorial/Web.html


    I would wish to have, a stripped down GT version of Template Toolkit, which has only the necessary features, and is faster than Template Toolkit.

    Best regards,
    Webmaster33


    Paid Support
    from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
    Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

    Last edited by:

    webmaster33: Apr 22, 2005, 4:44 PM
    Quote Reply
    Re: [webmaster33] [Suggestion] New GT template system In reply to
    There is a good example in the GT::Template::Tutorial, which shows the great possibilities of the new, improved LSQL v3.0 template system.

    Quote:
    Another useful example is in including a common header or footer to all pages. If, for example, you have a header.htm that you wish to be included, but it needs a variable title, you could combine the include with a set, such as:

    <%set Title = 'Login'%>
    <%include header.htm%>

    and then in your header.htm:

    <html>
    <head>
    <title><%Title%></title>
    </head>

    This would allow you to have different titles, but still include the same header template on each page.

    GT::Template also supports including a file based on the value of a variable by specifying the variable name (starting with a $) for the filename:

    <%include $var%>

    This allows for more powerful include abilities. For example, if you wanted to have a single outer template which includes another, variable template you could use an outer template (for the purposes of this example, assume this template is named 'outer.html') something like:

    <html>
    <head><title><%title%></title></head>
    <body>
    <div style="border: 5px solid black">
    <%include $inner_template%>
    </div>
    </body>
    </html>

    Then, inside other templates, you would do:

    abc.html:
    =========

    <%set inner_template = 'abc_content.html'%>
    <%set title = 'ABC'%>
    <%include layout.html%>

    xyz.html:
    =========

    <%set inner_template = 'xyz_content.html'%>
    <%set title = 'XYZ'%>
    <%include layout.html%>

    Now both abc.html and xyz.html would show up with the same page layout defined in layout.html, with a content section coming from their respective *_content.html templates.


    It provides almost all features I listed earlier.
    Directories - possible with <%include dir/file.html%>, so grouping is greatly possible
    Inheritance - already possible since a long time
    Variable files - possible to create variable files, where the tags are defined
    using <%set tag='sometime'%> then this is included using <%include file.var%>,
    then the <%include file.html%> is used, to display a file with changed variables
    Skeleton-like template structure - possible using the technology mentioned in above GT::Template::Tutorial, using variable files.


    3 important things are still missing from the GT template system:
    • Site level - missing
    • <%include $foo if%> - missing to include based on existance checking of currently used $foo variable
    • Multi-line set command - missing?

    There would be nice, if GT would provide a template set, which is based on a skeleton-like template set, and provide several color themes of it (using inheritance) to show the possibilities of the GT template system.

    Best regards,
    Webmaster33


    Paid Support
    from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
    Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...