Home : Gossamer Threads Inc. : Discussion :

Gossamer Threads Inc.: Discussion: Re: [GT Dev Team] Gossamer Links 3.0 - Template system changes: Edit Log

Here is the list of edits for this post
Re: [GT Dev Team] Gossamer Links 3.0 - Template system changes
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.

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.
<%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...)

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.

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.

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:

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.

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.

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:
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":

The Template Syntax page does NOT have the word "inheritance":

The Template Tags page does NOT have the word "inheritance":

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.

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,

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

Edit Log: