[Typo3-dev] Better templating: PHP!

[S. Teuber]

Hi Dan,

> Yes - and my original point is that php is a good 
> language to implement any "place holders" in because
>
> - it is quickly tested by non-TYPO3 html-ers

Not quite... because:

> All the html-er (note: NOT the TYPO3-er) has to do 
> to test this is create a file like:
> <?php
> $myHeader = 'blar blar blar';
> $myMenu = '<ul><li>Page one</li><li>Page two....';
> $myContent = '<p>this is some content</p>';
> include('myTemplateFile.php');
> ?>

This is not HTML, but PHP. So you need not an HTML-er, but an HTML-er 
with PHP knowledge to test this. This may sound like nitpicking, but the 
good thing about seperating code and layout is that the "layouter" has 
absolutly *nothing* to do with any programming language. This basic 
principle is spoiled by your approach.

Plus, the HTMLer needs a working PHP environment to test his files.



> - it *looks* like the old html

HTML with markers in it looks like HTML, too. Plus, it has the benefit of 
displaying where content will be inserted straight away. Something like

<div id="leftNav">###LEFTNAVIGATION###</div>

can be displayed on any computer with a browser (no need for Apache, let 
alone PHP to just check the basic HTML output), making it clearly visible  
where replaceable parts are and, using clever marker naming, what will be 
inserted there.


> - it is supported by lots of editors

Plain HTML with markers instead of PHP variables is supported not only by 
all (text) editors, but even by WYSIWYG editors...


You stated in your initial post that the advantage of your approach was:

> This has dropped debugging time from (approx) days per page to 
> (sometimes) seconds or (mostly) mins. 

I don't second that. What you do in your PHP file - filling variables and 
including the template - is nothing else but the standard procedure you'd 
use in a TYPO3 extension, just in different "words". Instead of doing:

$myHeader = 'My Header';
include('mytemplatefile.inc');

you can do

$markerArray['header'] = 'My Header';
$this->cObj->substituteMarkerArray($template, $markerArray);

I guess you will say now, "but you need to be in a TYPO3 context to do 
this, while my approach works without TYPO3! (plus, how do I get the HTML 
into $template?)"

True, but I see this not as a disadvantage, but as an advantage, because

- you'll need to implement the template in a TYPO3 environment anyway.
  When doing this, switching from "static" content that you provided 
  in the file mentioned above to "dynamic" content provided by TYPO3
  creates the need to test and possibly debug *again*, rendering any
  time savings made earlier useless

- many, if not most, contents for the markers will be generated by TYPO3,
  especially through TypoScript (think HMENU or styles.content.get),
  so inserting the content that's usually provided by TYPO3 manually into
  a file with PHP variable declarations is nothing but doing work twice

Plus, your approach needs new functionality to be implemented, as you 
already suggested:

> Ok, ok - the html-er could include some logic. 
> There are two ways around this: 1. check the php 
> for logic and remove any; 2. write a parser based 
> on token_get_all which will block any kinds of 
> tokens which you don't want (e.g. T_IF, T_INCLUDE 
> etc).
> 
> What about this?

I think the only advantage of your approach may be that it has less 
overhead than the fully blown templating mechanisms provided by TYPO3. 
It's faster and doesn't take up so many resources. I don't see it 
reducing debug time in the long run, though. 

But the gain in speed is just for now. With workarounds for security 
(removing logic etc.) and an added subpart handling (which is quite 
useful and often needed), it finally will be another templating engine 
which isn't as fast and slick as the plain thing but more bloated like 
any other engine.

Frankly, I don't think the "plain" version you introduced here suffices 
the demands for security and flexibility (combined), and a worked-on-
version will by any chance not be that different to existing solutions, 
anyway.

But I'm looking forward to be proven wrong, for that's how new technology 
evolves! :-)

Sven