Whilst I appreicate patrik is looking out for the community I don't think your comment was personal. Just the usual Hockey stuff I expected
Oh thanks
Whats that supposed to mean?
Indeed you are. Many great people were very subborn but that is because they had big ideas that other people didn't get.
Now your implying i'm great?

You too man...your fantastic
Not sure about big ideas...but people certainly don't understand me most of the time thats for sure.
Think about the justifications you have for your opinions. Take a comment you have said to justify something you believe in and then try to think of all the possibe arguments somebody else could use against it.
I do that all the time...by virtue of the fact I confess when I'm wrong, doesn't that imply I have considered both sides of a answer, decided on one, then later felt the other argument was correct so I switched opinions...
It's like battling with arborint about design patterns...I never seen a purpose in formalizing my understanding of the subject as they are basically practices and principles I have learned through osmosis over the years of development. But after much consideration I thought "meh" I'll read about the more common ones and what what 30 different people all preeching the same practice have to say might possibly persuade me. I can see the benefits.
iamsure convinced me over time of the importance behind xhtml validation, web accessibility and standards. At first I argued because it didn't seem economical to make the switch. Learning to write XHTML when every client I have ever had has never even mentioned it, didn't seem to make $$$ sense. But after some consideration and battling with myself, I decided he was right, so I dove into learning about web accessibility. Slowly but surely I'll get there, but for now it's enough to be convinced of it's importance and at least make a honest effort on future projects.
In this case though, I can't see myself stepping down as no one has provided any tangible reasons as to why Smarty should be used over PHP's native templating funcitonality.
Smarty adds un-nessecary bloat, when the same functionality can be easy emulated (chicken and the egg) using plain vanilla PHP. Perhaps you are unaware of PHP's inbuilt templating syntax???
Code: Select all
//
// class.tplengine.php
class PHP_Template{
function fetch($tpl_file)
{
//$tpl = $this; // proivide differnt this pointer name for templates???
// @extract($this->m_vars); // Smarty assign instead of expando properties
ob_start();
include($tpl_file);
$buff = ob_get_contents();
ob_end_clean();
return $buff; // Return PHP template
}
}
The template syntax can be very similar to that of Smarty's using PHP's alternative syntax
Code: Select all
<!-- test_template.tpl.php -->
<html>
<head>
<title><?php echo $this->title; ?></title>
</head>
<body>
<?php for($i=0; $i<10; $i++): ?>
<b>Test</b><br />
<?php endfor; ?>
<b>Author:</b> @AUTHOR@
</body>
</html>
Now you instantiate the PHP template object:
Code: Select all
include 'class.tplengine.php'; // Include the template engine
$obj = new PHP_Template;
//
// TODO: Implement custom advanced (useful) caching here if needed
//
// We could emulate Smarty's assign very easily, but this looks nicer...
$obj->title = 'Some title pulled from DB, etc';
$buff = $obj->fetch('test_template.tpl.php ');
// TODO: Perform some pre-rendering filters on templates
$buff = str_replace('@AUTHOR@', 'Hockey Knows Best', $buff);
echo $buff;
References to support my claim:
http://www.phppatterns.com/docs/design/ ... te_engines
http://www.massassi.com/php/articles/template_engines/
The above is a *very* trivial, I assume not very well known method of using PHP's built-in templating services *without* the over head of learning a new snytax or keeping another library up to date, etc.
It's fast, there is
ZERO compilation and it's more extendable/flexible due to the fact it's entirely done in PHP, so your not limited to obscure keywords like Smarty's
{section}
The *only* advantage I can see Smarty offering is the fact you can actually disable PHP in the templates, which may come in handy when you have anonymous users posting templates. If I recall correctly, template lite doesn't have that option eneabled by default where as Smarty does. We had a huge disscussion about whether this was a security flaw or not. I think the general census was that it was *not* a security flaw. So you be the judge as to how important it is.
Without that, Smarty doesn't hold a candle to PHP inbuilt templating...sorry...but your arguments don't hold up to the truth.
Your Argument: Smarty offers modifiers?
My Answer: Sure does. It's flawed though. Why would I want my designers to have exclusive control over how my dates are formatted? Date formatting is a setting typically set in locale section of your web site (admin panel, etc) Therefore it requires some kind of logic control in setting the date format.
You could hack around this and use a Smarty config file and perhaps have smarty use the config variable, but I'm not sure if thats even valid syntax. Not only that, but what if I don't want to store template modifier parameters in a Smarty config? What if I want all my admin options in a DB???
Second approach, you could really hack Smarty and pull those admin options from a DB and format the value in your PHP code...but in that case, you've circumvented a problem by hacking *against* a system which is supposed to help you. When you could have just stuck with PHP and been done with.
Your Argument: Smarty has a powerful recirsive template inclusion facility
My Answer: You can do the same using PHP. But it's bad practice!!! Why, again, would I want to let my designers have exlcusive control over when a particular template should be used?
What if the templates are designed in such a way, that one has a login FORM and the other has a user menu???
These 2 layouts would likely then have to duplicate template code inorder to fulfill these 2 requirements.
Code: Select all
<!-- Login Template: login.tpl -->
<form>
<input type="text" name="user" />
<input type="password" name="pass" />
</form>
<!-- User menu: user_menu.tpl -->
<ul>
<li>My Profile</li>
<li>My Bookmarks</li>
<li>My History</li>
<li>My Account Stats</li>
</ul>
<!--
2 templates may possibly be required one to include login.tpl and another to include user_menu.tpl.
Not sure how else you solve this in Smarty, but doing it this way causes duplicate code...
-->
<html>
<head>
<title>{$title;}</title>
</head>
<body>
<table>
<!-- Left hand side navigation -->
<td>
{include file="login.tpl"}
{include file="user_menu.tpl"}
</td>
<!-- Main document body -->
<td width="100%">
Some primary body content
</td>
</table>
</body>
</html>
By quickly scanning over the documentation for {include}
http://www.phpfreaks.com/smarty_manual/ ... clude.html
i can see they have solved this issue noted above using variable interpolation techniques, like a PHP string.
You would basically inside your controller logic, need to determine which page content template is to be displayed and set the name of the template in a variable and assign that variable to the Smarty object.
Ok, so that fixes the problem, but it's still a *hack* and it's slower than just doing the following, especially when you use straight PHP.
Code: Select all
$smarty->assign('test', 'This will be injected into my body template');
switch($_GET['page'){
case 'about':
$buff = $smarty->fetch('about.tpl'); // Pull the about us page
break;
case 'faq':
$buff = $smarty->fetch('faq.tpl'); // Pull the FAQ
break;
default:
$buff = $smarty->fetch('default.tpl'); // Pull the default
break;
}
//
// Assign layout title
$smarty->assign('title', 'Hockey knows best');
$smarty->assign('body', $buff); // Inject body buffer into layout template
$buff = $smarty->fetch('layout.tpl');
Same effect, more control and less *unessential* Smarty hacks...
The above method is just as easy to implement in the PHP template version and doesn't incur the Smarty costs...
Your Argument: Smarty offers built-in compilation and caching
My Answer: Yes it does. However Smarty templates are essentially compiled into the PHP version I have shown you above at the start.
I'll explain the compilation/caching process as how I understand it
You write a template file using Smarty syntax...you have several templates most of which are likely body content templates and one or more layout (navigation, etc) templates.
The body/content templates are injected or included (recursively I'm willing to bet) into the primary layout template. I like to distinguish the two as Frame and View from my MFC programming days
Templates all sit in a directory you tell smarty to lookup as well as a cache directory and compile directory.
When you first run your code, Smarty finds each invoked template file and performs a psuedo-compilation on the template, basically converting it to it's PHP equivelant (again, what I've shown you above). The Smarty system, the actually calls that PHP file and using the technique I have shown above, includes the PHP based template and lets PHP perform it's parsing magic and execution.
So really, what I've shown you above as a PHP template engine, makes this comppliation step redundant,
wouldn't you agree???
Redundancy, as you clearly understand as you inform me of good programming practice, etc...generally frowns upon code redundancy...it's bad practice these experts claim...
Anyways, after the compliation has completed...Smarty like I already said, actually includes the PHP version NOT the Smarty version...letting PHP do it's job...
However, here's the amazing part everyone loves so much...
Smarty, either using output buffering or catching the
fetch() return value before returning (i'm not sure) actually takes a snapshot of the generated web page and stores it in the cache directory.
Isn't that amazing???
Now, here is where I am unclear how Smarty works as after I came to these conclusions, I switched from Smarty to PHP templating...
But, experience would suggest...Smarty requires you to hardwire caching using it's API...
An API which lets you know whether a cache exists or not...
Code: Select all
include('smarty.class.php');
$smarty = new Smarty;
$smarty->setCacheDir('./mytemplates/');
$page = $_GET['page'];
if($smarty->isCached("$page.tpl"))
echo $smarty->fetchCache();
else{
//
// All that page selection code I've shown previously
//
}
That caching functionality is so basic...I could emulate it in minutes by customizing my PHP template class above.
What would be handy, is an event caching system. Where you could cache results of a threaded message forum and whenever someone posted or removed a message, then that page and others affected by change would inform the caching system to flush it's contents and start generating new ones...
So long as most visitors did nothing but read forum topics, this caching works like a charm and is actually worth talking about...
Most people don't spend time on static pages...like About Us, etc...they goto the dynamic sections which are difficult to cache or require customized caching services like I explained above...
Have you actually tried it or made any attempt to learn it? If you find it has no use for you that is perfectly acceptable, or if you aren't interested in the idea enough to investigate that is too. But you can't just slate something to hell without understanding exactly what you are slating.
I've written many differnt template engines, all experimental...but each using a different technique than the other. I have one of particular interest, which i'm sitting on...considering patent application as it uses quite a complex concept to solve many templating issues of current generation template engines
I may be off in my understanding of Smarty...if I am...please by all means...inform me...open my eyes to a world I clearly do not understand...
Cheers
