Hi!

We are thinking of making a major change in the template system and I'd like some feedback.

Currently, the templates are structured like:


What we want to add is a 'local' directory to that so it would look like:


The purpose of this directory is for you to store any customized templates. So for example, if you change the header and footer template, your changes would be saved in /default/local/header.html and /default/local/footer.html. Then the template parser would be smart enough that it would use default/local/header.html instead of default/header.html.

The template editor would also be smart enough to save your changes into local.

The goal here is that the templates in default are the ones that came when you installed the program, and the ones in default/local are your customizations.

When you upgrade, all default ones will just be replaced with the new templates, however your local ones are preserved. That way if you have just changed the header/footer, there is no work in upgrading. If you have made customizations you can compare the default one with the local one to see what has changed.

I hope I explained this well, but I have a feeling I didn't. =) Does this make sense? Is this useful? Can you see problems with this (one problem is people should not edit the default ones anymore as it will get lost in upgrades).

Let me know what you think,

Cheers,

Alex
--
Gossamer Threads Inc.

Good Idea for those who work off the original template sets, but how are custom templates in their own directory affected by this? Surly the purpose of having the "build_default_tpl" option in setup/build is to separate custom made sets from the originals thus preserving the originals - achieving the same objective as you are proposing.

Wouldn't this be feature duplication?



~ ERASER

---

Free JavaScripts @ Insight Eye

Alex,

Anything that makes my life easier during upgrades is a good thing. I just went through quite a bit of confusion with the search results pages no longer returning search_error.html or search_results.html upgrading from 2.0.3 to 2.0.5. (I would still like to know where I can modify the results placed in %error% so I can once again incorporate links to other search engines if nothing found in my own directory but I'll save that one for another post. I'll search a bit more first.) However, given the fundamental change in the way search results are displayed between these two versions, I'm not sure what you propose would have lessened my grief any.

Hi Alex,

U mean that the compiled templates are only examples, which u can copy/modify and then use it at your local directory.
Well why not make 1 directory and call it example ?

The structure u wanna use doesn't make any sense to me.

Hope it helps u.

Regards startpoint.

hola!

it will be a great enhance, thx Alex.
to me would be beautiful if it worked in this way:

hola!

I forgot to ask: will this enhance include the possibility to add specific (globals.txt, language.txt etc.) files within the main tempalte folder?

bye,

Alex,

I -think- I know what you are driving at, and I think it's a good change. It's something many people have suggested at several levels along the way.

If what I am seeing is:

/default/compiled/xxxx.html will be the template that ships with Links

and

/default/local/xxxx.html will be the template you've modified for your site

Then, it will be a great update.

If the template parser first checks

/default/local for a template, and if it finds it, uses it, (ie: overrides the "default") then this is also a good thing.

Only _MODIFIED_ templates need to be in the 'local' directory.

I can see this getting complicated, but for now, I'm sticking to the 1.0 version <G>

Perhaps changing "compiled" to "system" or even "default" would make it clearer. I know the /default/default would look funny, but the first "default" is a _name_ of the template set, and the second default would be the default set to use in the 'default' name space.

yahoo/default and yahoo/local don't look funny or bad at all.

The only "caveat" I see here with some of the suggestions, is that disk access is "expensive", and even problematic with various cache systems. The more directories that have to be "checked" increases the processing time, especially if 99% of the checks are going to yield no changes.

Using the fields in the category record, or even the link record, would be more efficient in that respect.

One change you might want to consider, and it's a "deep" change to the logic, is that people often treat their first level categories different. Sometimes their second levels as well. Maybe if you allowed a parameter in the CFG hash "Template Depth" which is defaulted to '0' (meaning no additional directory checks are made), but which could be set to 1 to check for a matching directory for top level categories, or 2 for second level categories, etc, and which would allow an override as suggested. This would cut the amount of checking necessary on "deep" trees, and still allow sites to have different template sets for the main categories (or turn that off) with a minor expense of a couple of 'if' tests in the code.

I'm probably less clear on this than you felt you were on the original post, but it's a suggestion :)




PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Yeah it's similar to VBulletin. Their template system always keeps a default set but allows you to customize them and lists them next to the default ones in the control panel so you can see which you've modified and which you havent - then upgrades only overwrite the default sets and not your customized version.