The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Okay what does that tell us? The presentation is greatly outsourced into files. The designers won't have to deal with any php code or code of another scripting language (other than Javascript if they want to use it - the php coder doesn't care).

Problem: He has to mess with HUNDREDS of files. Basically whenever I use a list of things I create a separate ****_list file template, that contains '<li>{VAR]</li>' or something. Now that is not very cool. The question is how can I mainatain all this decoupling while storing more template information in the different files? Sounds like using functions, but then again this would mean adding php code to the scripts. Any ideas here?

I might be coming across as being two faced (I'm not, let me asure you) but I've long been an advocate of keeping PHP out of HTML, as I've thought of it as breaking layering.

I still do, unfortunately I've taken steps to use PHP variables with HTML (where HTML is the markup, as in it ain't going to change) due to the needs of performance. Parsing the HTML template to look for your variables or tokens takes x amount of time.

Depending on the server usage, as this increases there is a performance lose. Caches help to some degree, but even these become stale after a while. So what I'm saying I suppose, is that maybe it's just as well to use PHP iterator's within the HTML, ie For outputting the data?

I'm not suggesting that you therefore place presentational logic in the HTML though, as that is going a bit too far

I've gone the "smarty route" when building a template system, compiling the templates over to php code.
Parsing templates at runtime is a lot slower than using the php parser, a _LOT_.
Its also easier to compile the template over to php than writing a parser (which was the first solution i tried and found to be too slow).

I just provide foreach-functionality and if/else to be used in templates. Without looping and control structures you will find the code you need to make a bit inefficient, thats my experience anyway.

If you can live with your markup being xhtml-strict, you could also use XSLT as a template-engine. Being (mostly) declarative in nature, it may be more intuitive for a graphic-designer to use than an imperative language. It also has some benefits in portability. Regarding performance, I would guess it to be faster than a custom regexp-based algorithm. (Not that this should be decisive for your choice, I think)

Thank you all for your contributions. So do you guys also go about having lots of different template files (whether you use loops and conditional structures or not) or do you wrap them up into functions somewhere so that you don't have to deal with lots of files?

What if you had some default ones that could be overwritten depending on the context/url/directory? EZPublish uses a neat override method that lets you override templates, depending on the "location" (fron-end, back-end etc...). There are lots of templates but as you get lower into the structure, you are inheriting from the parent directory (node actually) and override as needed. So, you'd have a default "List" template that would be used for all lists, but you could override at any point. etc...

Thank you all for your contributions. So do you guys also go about having lots of different template files (whether you use loops and conditional structures or not) or do you wrap them up into functions somewhere so that you don't have to deal with lots of files?

While programmers love decomposition, designers prefer to work with monolithic files because those look nice in their visual tools.

Being (mostly) declarative in nature, it may be more intuitive for a graphic-designer to use than an imperative language.

I can hardly imagine a graphic-designer that finds something like <xsl:template match="LINE[position()=last()]"> "intuitive".

One of the consequences of web development is that you will end up with a load of template files, just because of the nature of todays dynamic, interactive web sites and browser based applications.

Just ain't no way around it as far as I see it. But really, it isn't a problem or issue as far as a developer goes, unless of course you need to design as well. From the development point of view, we are only concerned of fetching the files in question, making sure they are outputted in the order of the page structure as required, and not pretty they look.

What does help though, is having a good relationship with the designer(s), as if communication is open and honest and discussion is clean ( ) then this is have the battle I think

Probably the only way to reduce the number is to put multiple template blocks into a single file where possible. I have found that this also helps designers to be able to work on the related parts together.

I don't like having too much template files. One (rarely two) is more than enough, with different blocks being parsed according to the application logic.
But it depends on your template engine (what features does it support), and how much time does it take to generate the output.

I don't like having too much template files. One (rarely two) is more than enough, with different blocks being parsed according to the application logic.
But it depends on your template engine (what features does it support), and how much time does it take to generate the output.

I use templates for everything, usually heirarchical templates. I tend to use simple HTML templates with tags or PHP templates. The template code I use is about 2k, as simple and fast as you can get, and supports both styles with the same interface -- I just change the filename if I want to switch. As much as possible I try to let designers work as they normally do.

The first paragraph was indeed in relation to it not being tested, and the second paragraph was in relation as a warning to others, as you are breaking any number of rules , for layering and object oriented good practices.

Anyways, I eventually calmed down, and on a more serious note I think the suggested Tags approach would be what your looking for. Harry had an example of this on his site, but it's down.

I tackled this a while back, of which I posted the script but that going back a while now, and I don't have the script at hand. In regards to this approach you can very quickly and easily build a complete page on the fly from Tag components.

Ie Each Component could be a section of page which has a class that would pre build it for you as you want it, so in that regards, it's just a case of appending it to the web page 'frame'...

The component is there for you to use, it's already build, so you get re-use, as if the page section changes, you don't need to change the client script which uses it... You just script a new component that is more readily suitable to your needs.

The reason I no longer use this approach, and this is a major point, is that cause the page is build on the fly, a web designer has little say in the matter, so their role is purely CSS.

The designer can't change the layout for example, unless they know PHP of course.

Just my "statistics" on number of files.
For the sites we run here at work there goes about 50 templates for one site. This is your average big online specialized newspaper. For an example check www.hardware.no
That is exluding forum and "external" services. Its just the article-related parts of the site.

And i have 0 templatefiles, they are all stored in db with a webbased template admin panel on top.