Yet another reason smarty sucks.

[aamonkey]

I never said anything about performance. I'm talking about maintainability. Do you ignore classes and objects because they're slower? Performance is a non-issue. Servers are cheap, development time is expensive.




Yes, you're right. But ignoring tag names, I can change the meaning of logged_in_user for the templates without affecting $user->isLoggedIn() which will more than likely be used in the code for all sorts of things. Yes "logged_in_user" becomes a wrong label and difficult to understand for those looking at the code now which is why I'd advocate better tag names to begin with but my point still stands, it's a single change rather than a lot.

A better example, then, and yes this is contrived too but similar real world (and more complex) problems do frequently happen:

I have a simple forum, I want to extend my it to have a section where only users with over 10 posts can do anything. I have various marked up buttons, links, forms, etc. If they are just marked up I can change the logic in one place. With php logic in the template I need to update each occurrence.

My point was not that trivial example but rather to show that including logic in templates creates unnecessary repeated code. As I said, it's like CSS inline styles vs an external stylesheet.

Keep in mind also, that by abstracting the logic to a separate class, the logic is entirely testable with phpunit/simApletest/etc.

That's great, but it doesn't require a (second) parser to accomplish this. You can just assign values to variables using whatever logic you like in your business logic layer, and pass those variables to the templates. It's essentially exactly what you are describing - without the extra overhead and without the need to learn a custom syntax. Why not use php for what it is best at?

[Lemon Juice]

I'm also wondering why use the extra parsing layer. Supposing your proposed 'returning user' and 'unregistered user' are what we want to check for then why instead of:

<returning_user>
Welcome back <?php echo $user->name; ?>
</returning_user>

<unregistered_user>
Welcome, Guest, Please login or register.
</unregistered_user>

don't we use this:

<?php
if ($user->isReturningUser()) {
?>
Welcome back <?php echo $user->name; ?>
<?php
}
if ($user->isUnregisteredUser()) {
?>
Welcome, Guest, Please login or register.
<?php
}
?>

This way we can keep isLoggedIn() method for all the other usage cases. This looks simpler to me.

[TomB]

That's great, but it doesn't require a (second) parser to accomplish this. You can just assign values to variables using whatever logic you like in your business logic layer, and pass those variables to the templates. It's essentially exactly what you are describing - without the extra overhead and without the need to learn a custom syntax. Why not use php for what it is best at?

1) You can skip that binding logic entirely.

2) and more importantly it lets you easily abstract away common display logic (see the pagination example).

3) It lets you have total control over what's possible without working PHPs syntax around it. For instance, I use code like this:

<tabsheet>
    <tab name="Tab 1">
        <h1>This is tab 1</h1>
        <p>foo</p>
    </tab>

    <tab name="Tab 2">
        <p>tab 2</p>
    </tab>
</tabsheet> 

Which is automatically translated into something like this:

<div class="tabsheet" id="tabsheet1">
    <ul class="tabheader">
        <li id="tabsheet1_1 current">Tab 1</li>
        <li id="tabsheet1_2">Tab 2</li>
    </ul>
    <div class="tabpage current" id="tabsheet1_page1">
        <h1>This is tab 1</h1>
        <p>foo</p>
    </div>
    <div class="tabpage" id="tabsheet1_page2">
        <p>tab 2</p>
    </div>
</div> 

Which displays a set of tabs and pages that maps directly into my existing CSS and javascript and just *works* without any messing worrying about attaching the javascript events, getting element ids/names right. All the generation logic is abstracted away and even supports nesting. It makes for very fast built templates. I have various other components including a headed, potentially draggable box which I just use <box title="Box">Contents</box> rather than multiple divs. If I need to change the way the box is drawn, it's its own template in one and it will affect the site globally. I have similar componentalised form generation. Where this is especially useful is for mobile browser versions.

I'm also wondering why use the extra parsing layer. Supposing your proposed 'returning user' and 'unregistered user' are what we want to check for then why instead of:

This requires knowledge that things may change regarding that condition. What if that changes to $user->isReturning() && $forum->minAccountAge < $user->accountAge()*. My point is, you can't know how things will change. As I stated previously, it's the equivalent of CSS stylesheets vs inline styles. I can essentially update the "stylesheet" (the logic) in one place and affect everything.

*Again, think beyond this trivial example to real-world scenarios where things do change all the time.

[TomB]

er... the auto-generated ids are needed so the javascript can automatically link the tab buttons to the content.

[Michael Morris]

Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).

id="tabsheet1_1 current" is not valid markup since there are 2 ids there.

[ScallioXTX]

Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).

Indeed. One element can have zero or one id's, but not more.

[TomB]

Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).

id="tabsheet1_1 current" is not valid markup since there are 2 ids there.

Off Topic:

yep sorry, was supposed to go in the class name, I was only typing that out for demonstration purposes

[Lemon Juice]

Elements aren't supposed to have multiple ID's. (I'm 95% sure of that).

Then become 100%

id="tabsheet1_1 current" is not valid markup since there are 2 ids there.

Correct, it shoud be

id="tabsheet1_1" class="current"

or something similar

Edit: It looks like my post was almost simultaneos with the previous ones...

[rguy84]

The introduction of the logged in tags made me laugh. You'd rather write a new doctype vs making a php function? Same with the tab.

[TomB]

It's not a new doctype? It gets translated into html. The markup itself is valid xml.

Whereas:

<div class="<?php echo $className; ?>"></div>

Is not.

[rguy84]

is not where? When parsed?

Also, Turning <tabsheet> into a nested div requires that your browser does parsing. Somewhere something must tell it to do that. To my knowledge, tabsheet is not a valid html tag.

[Michael Morris]

It's not a new doctype? It gets translated into html. The markup itself is valid xml.

Whereas:

<div class="<?php echo $className; ?>"></div>

Is not.

Who cares if server side preparse files are valid as long as they parse into valid markup?

[rguy84]

Who cares if server side preparse files are valid as long as they parse into valid markup?

exactly my thoughts. if somebody is worried about preparsed, you can't use anything other than html, not even, gasps javascript

[TomB]

is not where? When parsed?

Also, Turning <tabsheet> into a nested div requires that your browser does parsing. Somewhere something must tell it to do that. To my knowledge, tabsheet is not a valid html tag.

On the server... in php... which this entire thread is about

Who cares if server side preparse files are valid as long as they parse into valid markup?

My IDE cares, it lets me use the full extent of the HTML/xml editing capabilities if it's valid.

[rguy84]

On the server... in php... which this entire thread is about



My IDE cares, it lets me use the full extent of the HTML/xml editing capabilities if it's valid.

so, you made a function that allows you to made random tags, then parses those tags to valid ones?

If no, how does

<tabset>
<tab>tab 1</tab>
... or whatever

become

<div class="tabsheet" id="tabsheet1">
    <ul class="tabheader">
        <li id="tabsheet1_1 current">Tab 1</li>
........

without needing an external source to tell the browser how to handle the <tabset> and <tab> tags?

[TomB]

Yes. A php function translates it. It *could* equally be done by XSLT on the client.

[Michael Morris]

On the server... in php... which this entire thread is about



My IDE cares, it lets me use the full extent of the HTML/xml editing capabilities if it's valid.

If your IDE chokes on the presence of valid PHP tags you need another IDE.

[TomB]

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.

[Michael Morris]

Eclipse and Zend have no problem ignoring PHP tags when validating XML. Just say'n.

[TomB]

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>

[Michael Morris]

Ah. I'm running 8.

[TomB]

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.

[pittendrigh]

I'm doing cleanup today on a legacy project at work that uses smarty. ............?

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.

[Michael Morris]

You're preaching to the choir. I didn't build the thing, I just have the job of maintaining the SOB.

[TomB]

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.

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.