I think a problem here is when you decide to blend two projects that started out separately. With a templating system (some anyways :) you can just redefine the main layout for each page being merged into the larger project in a single centralized location. The approach described above would appear to require in depth modification of the application's "template API".
The template api is a functional description of the backend capabilities you are exposing to the templates. They shouldn't have to change unless you are making changes to those backend capabilities. The templates themselves provide the markup and location of these various components of the application. The stack looks like this:
http://talks.php.net/show/lca05/58
So if you are blending things together you will at most need to change the top two layers.
I don't think that templates have a dependency between the number of pages using the template and an increase in the number of functions. In fact depending on the template, and the template engine, you can have 500 pages using the template and not a single function call. Including the elimination of include() and include_once() calls since if the template engine compiles to PHP it can do the includes at compile time rather than punting to PHP to do at run-time.
While compiling to PHP is by far superior to the various terrible eval() and regex-based templating layers out there, it is still dog-slow compared to tight specialized PHP code. Just instantiating the base Smarty class, for example, takes a very long time. I optimized a Smarty site a while back where I got a 50% speedup by migrating the base Smarty class to C in an extension.
So while how you want to separate your business logic from your layout and content, which to me are actually 3 levels of separation, is a religious thing, performance is not. Even though most sites don't get anywhere near the traffic of the stuff I deal with at Yahoo!, it still makes a difference whether your pages get served up in 80ns vs. 500ns. The 80ns page starts rendering right away with no latency and the whole thing has a perceptible crispness to it.
This works, but now what happens when your client/boss requests that the operating system choice not be a multi-select list but rather checkboxes and those check boxes should be 3 columns wide. The convenient select_any_of() function is no longer usable and while I know you can still use PHP as the template language, it surely doesn't look as neat as the above. Now add validation error messages, javascript events, and other stuff that is usually required in a real life situation. The source starts to get difficult to read and maintain as you switch in and out of PHP, HTML, and Javascript :)
You simply change the select_any_of() API function, or make another one. There are 3 levels of separation here. For large projects you have people who provide content. In this example, these are the people writing the actual polls. They are not web designers, they don't know any Javascript and next to no HTML. They simply provide the content for the application. Much like a journalist would provide content to a news site. The next layer down is the HTML/Javascript and whatever presentation layer magic you need. And finally, the 3rd layer is the business logic which is where your database calls and real meat of your application resides. In this 3rd layer there is absolutely no HTML nor Javascript.
-Rasmus
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
