Re: Real world usage of IT [template] class?

On 04.08.2002 12:26 pm, "Bertrand Mansion" <bmansion@mamasam.com> wrote: > le 8/04/02 17:46, derek fong à pear@subtitled.com a écrit : > >> Hi, >> >> I'm basically just trying to brainstorm ideas on how to properly structure >> the code for templates at a low level. I think the page you pointed me at >> is a good basis. But for me, my concerns are more along the lines of what >> actually goes into the PHP script that calls the template logic? It seems >> to me that if all template parsing is done by a centralized function (since >> reproducing it in every single PHP script seems redundant since it's all >> doing the same thing anyway, i.e., load the template file, parse it, display >> it), it's theoretically possible that nothing needs to be put into the PHP >> script itself except for the actual static content of the page. And this >> also poses some conceptual problems for me. If I have a global, site-wide >> template file structured like this: >> >> <html> >> <body> >> {CONTENT} >> </body> >> </html> >> >> Then doesn't that mean that in order to change the content portion (which >> would be straight HTML), a designer would have to go into the actual PHP >> script? Doesn't that negate a major advantage of using templates in the >> first place, in that designers should never need to see a line of PHP code? >> Or does that mean that {CONTENT} should be replaced by a file block which >> contains the HTML content for the page, and that that file should be placed >> in a separate repository for designers to manipulate? So you'd basically >> have a directory structure like so: >> >> /templates >> site.tmpl.php (contains global navigation and look-and-feel for whole >> site) >> /includes >> parse_template.inc.php (functions parse the site template for each page >> in public_html) >> /content >> index.tmpl.php (contains static HTML page content) >> page1.tmpl.php >> /public_html >> index.php ("dummy" scripts since they don't really do anything) >> page1.php >> >> My apologies if what I'm asking isn't clear, but I'm still trying to get my >> head around some of these concepts and how to make them work in the best >> possible way to separate the code from design, while at the same time making >> sure that it's not too "heavy" and easy to extend the system later if >> necessary. >> >> -f > > Derek, > > If all you want is display HTML static content, just use HTML files as they > are much faster to parse. Otherwise, your directory structure looks fine to > me. Maybe I would just put template and contents in the same directory. > > The other alternative in the case your content doesn't change much is to use > Smarty which create pre-parsed (cached) templates, thus avoiding to reparse > the php code all over again (http://www.phpinsider.com) which represents > gain in time. > > bertrand Hi Bertrand, I don't mean to imply that the content is 100% static, but in some sections (let's say, in the Corporate Profiles section) there is very little need for dynamic content, since a corporate profile is just an image and some text, all laid out in HTML. In this case, am I better off creating separate template files for each corporate profile with the HTML content on them already (since they won't change much) or should I keep the global site template as-is and just put the static content itself into its own separate block file for each page? So, something like: /templates sitewide.tmpl.html content/ corporate/ profile1.tmpl.html profile2.tmpl.html support/ index.tmpl.html /public_html index.php corporate/ profile1.php profile2.php support/ index.php kb.php A disadvantage to the first method is that changes to the sitewide layout necessitate changes to several files (i.e., we'd have to modify each corporate profile template, in addition to the site-wide template file(s)), while two disadvantages to the second method is that there's an extra "level" of files to edit and you're effectively duplicating the public_html directory structure somewhere else. Still, I'm leaning toward the second solution just because it seems less likely that someone will need to edit both the look and feel of the page and the content of the page at the same time, but maybe there are other methods I should consider? The goal here is to produce something that allows a designer/publisher to modify the content of a given page (there may be both static and dynamic content on each page), be able to make sitewide changes to the look and feel of the site with little trouble and (of course) separate code from design. -f