[TYPO3-dev] Moving the topic of the discussion a little bit -- Based of thread "Change roadmap..."

[Michael Scharkow]

Dimitri Tarassenko wrote:

> I agree with the article in general. However, in practice Smarty has
> one great effect that I noticed myself: the fact that full range of
> PHP functions is NOT available within the template actually enforces
> the business logic/presentation separation that is advocated in the
> article. Otherwise, it's sometimes TOO tempting to just call a couple
> of functions in the template when you really need to handle it in
> business objects. Sounds familiar? ;).

Yes it does, but I don't completely buy this argument because after all 
it's US who creates and maintains the logic *and* the presentation. So 
you can just try to be disciplined and not mix logic into the template. 
I think this is entirely possible without technical restrictions. 
Moreover, in a normal MVC situation you would call a view template only 
with local (method) namespace available, so the 'risk' is quite low.

The argument reminds me of the JAVA advocates who say: static typing and 
public/private properties force you to do write better code because you 
cannot use any shortcuts (like setting properties without accessor 
methods, or calling functions with wrong object types). The Python 
language does not have private/public properties, but only advocates the 
dev's discipline by naming private stuff __foo__. This works just as well.

> One other important issue is that I am not afraid to let site users
> (who are not PHP developers) edit Smarty templates, but I probably
> would never let them edit something that is going to be executed
> as-is.

Okay, I admit I did not think about general templating for TYPO3. I 
agree with Joey and everyone that we should make this pluggable for 
everyone's taste. I am mainly worried about the core and system 
extensions, which are maintained by us, so you can trust the template 
editors. For this, I find PHP is the ideal solution because it offers 
maximal flexibility without any overhead. And anyone mixing business 
logic into our code will tarred and feathered ;)

Greetings,
Michael