Of course, your comments are welcome!
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. 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.
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.
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.
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.
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:
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 :)Also I hope, you don't think that all users, especially advanced users are still using the admin interface to edit templates. 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"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.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.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.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...