Alex, Everyone, etc.... 
I just redid a demo site, and was able to use one template to reconstruct all the pages. I noticed that in some cases the "content" area was a single tag, and in others (the forms) a bit more complex.
Also, that the only thing in the rest of the template that changed was the TITLE tag and the status line tag because "<%site_title%>:Ultimate location " was different.
Ok, follow along.
If nothing else in the templates changed -- or could be included in an %include% tag, then what is the point of all the templates with the same code -- and the tendency to make tweaks that are not portable.
Ok, What occurrd to me:
1) all (and I do mean all) template writes need to go through HTML_Templates.pm
2) each load_template call from the subroutine includes a { page_name => page_id} entry that is filled from a hash defined at the top of the file as %TEMPLATES {page_name => [page_id, Custom_Template]}
Each template write that is added to the program gets an etry in the HTML_Templates.pm file in the export list, %TEMPLATES list and a sub new_sub_name.
3) Each subroutine is responsible for defining itself, and yanking the page_id from the %TEMPLATES hash
4) This has defined a page name and id to be passed to the templates, so at the top of the page, the page could be defined as <%site_title%> : <%page_name%> and the page_id is available for advertising use such that <%page_id%><%random%> would generate a "series" number for tracking, and other uses. It would also allow the template to inlcude different advertising based on the values.
5) In the navigation bar area, the page_name tag could be used to turn linking on/off for a more professional look to the page layout. (I've also put the whole navigation bar into an include file, so it's only changed in one area)
6) In the various &load_template calls, the templates could be defined as:
if $TEMPLATES=>{Custom_Template} $template = $TEMPLATES=>{Custom_Template} otherwise %template=$default
7) That provides wrapper flexibility.
8) Now for the template's "content area" itself. That could either be an <%include%> file, in which case you'd still be editing a couple of dozen much smaller files (without the redundant code), or a single data file with all the code by section. The section name could be put into the %TEMPLATES hash, as the second (required) parameter -- [page_id, tag_name, Custom_Template] This would allow for a data file with multiple formats. If the data file was read in, and entered into above hash, it would be a single
read of a small amount of data.
What this does, is allow a single generic template, with replacable parameters to load a <%content_area%> or <%include content_area%> tag.
All calls go through HTML_Templates.pm which is a user-editable file, with virtually all the changes to the %TEMPLATES hash, (unless they add a routine, in which case it's 3 changes)
If user changes were put at the end of the file, an upgrad would consist of pasting the middle of the new HTML_Templates.pm in over the old "library" routines.
I ended up with the following basic template format:
<html header> -- page defintion
<header> - my look
<advertising> - my advertising bar
<navigation_bar> - navigation bar
<content_area> - the only changing area
<footer) - my closing comments, copyright, etc
<html_footer> -- page closure
areas. I created a tag <%table_open%> and <%table_close%> to help create blocks in the page that were more readable than actually inserting the HTML.
I haven't actually implemented the various automated steps above, but this is essentially what I was doing when I created the new set of templates for the demo site. It shouldn't be much more complicated than the above, and it would get rid of alot of templates with single line changes, and improve the look/feel of the site into a single look with only ONE change of a file. If you wanted special templates they could still be added, by using the Custom_Template tag. The various parameters to be set could be expanded, but these are the basics, and it groups them into one area, one file (plus a data file) it makes sure all writes go through this file, and whould help unify the dynamic and static build routines.
If people are interested, you can see the templates in action at
http://www.postcards.com/cgi-bin/pcSQL/page.cgi?t=BA
(Theres a slight oddity for some browsers on the new and cool pages, because the templates use the nph-build/links.html combo from the demo site but I have to use the old nph-build until I update the live site... so that's due to extra/missing <TR> tags)
This is a group of templates all from the same shell, literally cut/pasted the content area in, and generated them in about half an hour. It would have gone much faster if I had the <%page_name%> tag, since I had to
remember to edit 2 or 3 places in each file to change those. I did not change the advertising bars, that's the next step, so all of them generate about the same tag xxx<%random%> or something like that, whereas in the version above, they could generate <%page_id%><%random%> tags, and be different on each page.
Comments? Things I've over looked? Problems?
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/
I just redid a demo site, and was able to use one template to reconstruct all the pages. I noticed that in some cases the "content" area was a single tag, and in others (the forms) a bit more complex.
Also, that the only thing in the rest of the template that changed was the TITLE tag and the status line tag because "<%site_title%>:Ultimate location " was different.
Ok, follow along.
If nothing else in the templates changed -- or could be included in an %include% tag, then what is the point of all the templates with the same code -- and the tendency to make tweaks that are not portable.
Ok, What occurrd to me:
1) all (and I do mean all) template writes need to go through HTML_Templates.pm
2) each load_template call from the subroutine includes a { page_name => page_id} entry that is filled from a hash defined at the top of the file as %TEMPLATES {page_name => [page_id, Custom_Template]}
Each template write that is added to the program gets an etry in the HTML_Templates.pm file in the export list, %TEMPLATES list and a sub new_sub_name.
3) Each subroutine is responsible for defining itself, and yanking the page_id from the %TEMPLATES hash
4) This has defined a page name and id to be passed to the templates, so at the top of the page, the page could be defined as <%site_title%> : <%page_name%> and the page_id is available for advertising use such that <%page_id%><%random%> would generate a "series" number for tracking, and other uses. It would also allow the template to inlcude different advertising based on the values.
5) In the navigation bar area, the page_name tag could be used to turn linking on/off for a more professional look to the page layout. (I've also put the whole navigation bar into an include file, so it's only changed in one area)
6) In the various &load_template calls, the templates could be defined as:
if $TEMPLATES=>{Custom_Template} $template = $TEMPLATES=>{Custom_Template} otherwise %template=$default
7) That provides wrapper flexibility.
8) Now for the template's "content area" itself. That could either be an <%include%> file, in which case you'd still be editing a couple of dozen much smaller files (without the redundant code), or a single data file with all the code by section. The section name could be put into the %TEMPLATES hash, as the second (required) parameter -- [page_id, tag_name, Custom_Template] This would allow for a data file with multiple formats. If the data file was read in, and entered into above hash, it would be a single
read of a small amount of data.
What this does, is allow a single generic template, with replacable parameters to load a <%content_area%> or <%include content_area%> tag.
All calls go through HTML_Templates.pm which is a user-editable file, with virtually all the changes to the %TEMPLATES hash, (unless they add a routine, in which case it's 3 changes)
If user changes were put at the end of the file, an upgrad would consist of pasting the middle of the new HTML_Templates.pm in over the old "library" routines.
I ended up with the following basic template format:
<html header> -- page defintion
<header> - my look
<advertising> - my advertising bar
<navigation_bar> - navigation bar
<content_area> - the only changing area
<footer) - my closing comments, copyright, etc
<html_footer> -- page closure
areas. I created a tag <%table_open%> and <%table_close%> to help create blocks in the page that were more readable than actually inserting the HTML.
I haven't actually implemented the various automated steps above, but this is essentially what I was doing when I created the new set of templates for the demo site. It shouldn't be much more complicated than the above, and it would get rid of alot of templates with single line changes, and improve the look/feel of the site into a single look with only ONE change of a file. If you wanted special templates they could still be added, by using the Custom_Template tag. The various parameters to be set could be expanded, but these are the basics, and it groups them into one area, one file (plus a data file) it makes sure all writes go through this file, and whould help unify the dynamic and static build routines.
If people are interested, you can see the templates in action at
http://www.postcards.com/cgi-bin/pcSQL/page.cgi?t=BA
(Theres a slight oddity for some browsers on the new and cool pages, because the templates use the nph-build/links.html combo from the demo site but I have to use the old nph-build until I update the live site... so that's due to extra/missing <TR> tags)
This is a group of templates all from the same shell, literally cut/pasted the content area in, and generated them in about half an hour. It would have gone much faster if I had the <%page_name%> tag, since I had to
remember to edit 2 or 3 places in each file to change those. I did not change the advertising bars, that's the next step, so all of them generate about the same tag xxx<%random%> or something like that, whereas in the version above, they could generate <%page_id%><%random%> tags, and be different on each page.
Comments? Things I've over looked? Problems?
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/