Re: [Fwd: Re: [PEAR-DEV] MVC revisted]
| From: | Philippe Jausions | Date: | Tue, 11 May 2004 21:50:04 +0000 |
| Subject: | Re: [Fwd: Re: [PEAR-DEV] MVC revisted] | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-29125@lists.php.net to get a copy of this message | ||
Stephan Schmidt wrote:
Agreed, the template engines work very differently. However, no matter how complicated or simple they are, there is always a way to bring the whole thing down to a simple interface. I'm not saying that everything should be trashed to only offer that interface, but at least that interface should be offered to ease code reuse in applications that don't want to or can't be tied down to one particular template engine. Each and every "power features" are useful to those engines and should be maintained. With PHP5 things like double data reading could be avoided by using iterators (i.e. getting the whole DB records vs. passing a SQL query resource ID.) Getting a template from a database, file or variable can be handled by streams. And last but not least, if your presentation logic needs to build blocks or whatever that is not directly included in the template file, then this logic could be encapsulated in a "template" instance (not engine.) Then that instance can be passed to the interface and used simply. I never said it would be simple or straight out of the box ;-) But ultimately, thinking about the template engine as a black box would be beneficial because it is closer to the MVC design. So this also means, that all initialization, configuration should be done before the template is passed to the application. Again, IMHO an application using a template engine shouldn't be more than take a template, give it to the engine along with data and getting back the result. -Philippe http://www.11abacus.com/Since PHP5 helps code interfaces I think it's a good way to go. In a framework a template engine should be seen as a black box. We feed a template and data, and we ask for the result. We should care if the engine uses blocks, tags, pseudo code or if the template is a string, a file or taken from a database.I'm sorry, but something like this will *not* work, when it comes to template engines. I have developed a template engine that provides several features that are not provided by common engines. The architecture is split up in a dozen of smaller classes, e.g. I got a reader class that is interchangeable which allows me to read from files, databases, or whatever you like. Template engines differ extremely in approach and feature set, so there's no way that HML_Template_IT, Flexy, Smarty and patTemplate will provide a common API for different features. Stephan