> > You're missing the point just because he threw in some old HTML > > styling attributes. The main issue is the overhead of added parsing > > layers to find where content goes in the HTML. Aren't we already > > using a language (PHP) that parses for place holders for dynamic > > content within HTML tags? Write the template in XHTML, style it with > > CSS, and insert content place marks with PHP short tags. Do the > > programming work of calculations, validation, and DB access in another > > script which will include the template at the appropriate time. Even > > create classes to hold various data sets (think JavaBeans) if you > > want. Adding a layer of abstraction just so your designers don't have > > to write <?=$var?> is silly at best. At lest that's my opinion. Do > > whatever works for you. > > > > Mike > Completely agree. A year ago, we got a IBE project. It based TYPO3 and Templavolia. After completion, it slow like hell. Then some optimization, some TYPO3 tweak. And still slow like hell. Then I realize, we got more than 20 template pieces in a page. (it was something about the travel business you have to show lots of different travel options in landing page). Anyhow, then I found a f*ckin simple thing. ob_start(); require(template.php); $output. = ob_get_clean(); With converting templates to php and opcode cache compatibility (yes your template was a php file so it was stored in the memory). things was become blazingly fast. Then we covert entire thing to php based templates. Things become much more flexible and fast. Of course there where a thin red line. Do not put writer functions in the templates. Other than that. Perfect solution. Except one condition. Your designers must have php enabled. Regards Sancar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
