Yes. A php function translates it. It could equally be done by XSLT on the client.
If your IDE chokes on the presence of valid PHP tags you need another IDE.
A “valid” php tag in an XML attribute causes validation errors which means I can’t get a quick overview of where any markup errors are using the IDEs xml validator, which is useful for quickly identifying mismatched tags and other syntax errors.
Eclipse and Zend have no problem ignoring PHP tags when validating XML. Just say’n.
Zend Studio 7.0 html and xml editors give the error:
-Invalid character used in text string
-Start tag (<div>) not closed
on:
<!doctype html>
<html>
<head>
</head>
<body>
<div class="<?php echo 'foo'; ?>"></div>
</body>
</html>
Ah. I’m running 8.
You sure you’re not validating it in the PHP editor? In which case it wont check the HTML/XML anyway. a < in an attribute should give a validation error, i’d say it’s a bad thing if it allows it.
Templating languages considered harmful?
I have never seen the value of any templating language. At least not so for an interpreted language. In Java coding they can be handy, because they do allow you can change application output by editing html fragment files, without recompiling the jar file. In PHP I’ve never seen the point.
Pundits invariably say “templates help separate content from logic.”
But to the contrary, they do just the opposite. They complicate debugging by pushing content into a parallel maze of annoyingly ugly looping, if and else logic constructs. If you find HTML errors you now have to search in at least two places (tpl files and/or the calling PHP functions) to find the trouble.
I use a system that defines content divs in a small and cleanly-nested XML file. My home-rolled cms spits out the divs, as found inside the XML, and then fills the div contents as needed. Sometimes content comes a file_get_contents() on a fragment file, sometimes a database call and sometimes a plugin function call. Debugging is easier. Cleaner. Each div contents comes from an atomic source (not a maze of hard-to-find tpl archives). You hand edit a fragement file. Hand edit an SQL select, or debug a clearly identified plugin class.
…Want to find a problem output in a typical tpl directory? It’s all too often
redined 2 or 3 times over, in different tpl files files, called by ever-changing runtime conditions.
In my system each URI can specify a different layout parameter, which maps through to a different XML file. Appearance is governed by CSS. There could be a thousand other such non-templating solutions–also cleaner and easier to deal with than annoying templating syntax.
You’re preaching to the choir. I didn’t build the thing, I just have the job of maintaining the SOB.
Your criticisms here are a straw man. You’re arguing against poorly designed systems rather than template systems specifically, either template systems or non-template systems can suffer these problems. In fact having to search through repeated display logic is a problem more common to not using template systems because reusing display logic is difficult.
…Want to find a problem output in a typical tpl directory? It’s all too often
redined 2 or 3 times over, in different tpl files files, called by ever-changing runtime conditions.
This is exactly the reason for templates.
By mixing logic and markup there is a necessary need for repeated logic. You will end up repeating conditional logic, loop structures, etc. By removing this from the template it is entirely reusable with different templates (or the same template with different logic!). If you have logical conditions and control structures in your template it’s not and encourages a copy/paste attitude to repeated display logic or places where something slightly different needs to happen.
The other huge benefit is an otherwise impossible level of testability. By moving the logic away from the markup the logic can be properly unit tested (see my post a few pages back.) If you’re mixing HTML and PHP, unit testing is out of the question.
RE> “Your criticisms here are a straw man…snipped…In fact having to search through repeated display logic is a problem more common to not using template systems because reusing display logic is difficult.”
Content in templating systems is still not in any way separated from logic. Now it’s wrapped in yet another messy system and syntax. I find they make debugging more difficult.
I see this as a post tables-layout-era HTML specific issue. With templates, if you want to re-arrange a layout, fiddling with tpl files is seldom enough. You have to grep blindly through PHP libraries to find all the places that tpl was used.
There are more intuitive and less clumsy ways to map div contents to the codes that produce it. I predict (five years from now) templates will be like Corba. Time will tell.
I don’t understand ‘content’ here… in 99% of cases the content will be coming from a data source such as the database.
I see this as a post tables-layout-era HTML specific issue. With templates, if you want to re-arrange a layout, fiddling with tpl files is seldom enough. You have to grep blindly through PHP libraries to find all the places that tpl was used.
I’d argue the exact opposite… with templates you can update 1 file and affect everywhere it’s used without needing to worry about the display logic running it.
Two examples:
-An added field ‘Also include the RRP in product lists’. With reusable templates, I make 1 file edit and include the new variable appears everywhere the template is used.
-Change the requirements ‘Don’t show products which have been out of stock for over a month’. Change the logic in one place and it affects all templates which use the logic. The same logic can be used for templates for search results/category listings/products by manufacturer/similar products/etc even if the layout of each page is entirely different because they use different templates.
Without this clear separation of logic and markup I need to locate and edit every instance of a list of products… messy.
Good advice, I agree (I hated it, too).
Good points. Also, the tag-based syntax does have good use-cases.
Example:
Smarty:
{$title|lower|escape}
PHP:
<?php echo htmlspecialchars(strtolower($foo),ENT_QUOTES,'UTF-8'); ?>
To a PHP developer, PHP statements are of little concern. However for a web designer or non-programmer, the tag syntax is a huge welcome with plain english words.
Is Smarty for everyone? Nope, and it never claimed to be. Much of this boils down to your own requirements: if you have PHP developers managing templates, a tag-based syntax may be of little importance. For a web designer or non-programmer, the latter is a huge welcome. Where the benefit really comes into play: such as a CMS/Wiki where templates are edited via a web interface by Joe Shmoe. Content with {tag} placeholders are by far easier to read than PHP statements, less error-prone, and minimize the learning curve.
Of course templates can be abused with poor implementations. It should go without saying that Smarty still requires a level of competency from the developers and designers.
It seems (by browsing around these forums) there is basically a one or two man army on a rampage against Smarty. I’m all for constructive criticism, but please backup your points. Bug ridden? By all means, point them out!
As for the isset() concerns, this is certainly a known one and is being addressed. Check the dev forums for discussions on that topic. As of Smarty 3.0.5, the templates simply follow the PHP error reporting level or you can set a Smarty-specific one.
Cheers!
Thanks mohrt, it is pretty good to see you in Sitepoint Forums.
Smarty 3.0.x really looks beautiful.
As I am using Smarty since its early days, the change was really adaptable.
It has really become flexible as well.
For other users, if you simply hated Smarty without organizing it correctly, please consider revising its manual first. Even the .chm distribution of old version still works as a good reference. However you are always free to dislike it if you think using Smarty causes poor design in your architecture.
I don’t even suggest to write non-reusable smarty plugins, because it is likely to contain a major part of your business logic.
@TomB:
Regarding the data sources, you can directly assign your database objects and access them in a template loop to save time and memory. But still pulling unnecessary data (that you may not show in the page) isn’t good again.
The concept behind Smarty is very good. Rather we can discuss on what would have made it even easier to use, without having to confuse with normal programming or other general template engines.
Hope to see you everyone using a template engine comfortably.
Interesting stuff. However, how is this so different from:
{if $returning_user}
Welcome back {$user.name}
{/if}
{if $unregistered_user}
Welcome, Guest, Please login or register.
{/if}
Does this not implement the same concept of separation? Or are you thinking of some further control from the business side, like manipulating/replacing content within the block?
At it’s most basic level yes. registered_user has become meaningless outside the template. This is a good thing because it’s no longer rooted in business logic. The meaning within the template can be updated and affect only the template. Consider it like a CSS class name, although meaningful in CSS it has no bearing on the data or structure of the element it’s describing.
As I said previously, it’s not an issue with PHP syntax vs custom syntax but one which is often ignored. However, custom syntax template engines are in a better position to provide an eloquent solution.
Consider this basic example (demonstration only…):
interface TemplateRule {
public function process(Template $template);
}
class TemplateUserCheck implements TemplateRule {
protected $user;
public function __construct(User $user) {
$this->user = $user;
}
public function process(Template $template) {
if ($user->isLoggedIn()) $template->showSection('returning_user');
else $template->showSection('unregistered_user');
}
}
//...
$template->addRule(new TemplateUserCheck($user));
I’d really go for a mix of a push/pull approach as I explained in post #16 for reusability purposes, but as a simple example that should give an idea of what I mean.
By completely decoupling the display logic from the template you have two way reusability, both the templates and the logic behind them. This also adds an otherwise impossible degree of testability.
Or are you thinking of some further control from the business side, like manipulating/replacing content within the block?
It adds the possibility. look at my reusable pagination example. That’s a case of reusable logic rather than strictly separation of concerns, but it’s that separation which allows for reuse.