Yet another reason smarty sucks

PHP
21

my favorite way to use smarty:


{php}
$vars = $this->get_template_vars();

// ... do whatever
{/php}
22
Off Topic:

:rofl: Ok, now you’re trolling. I hate smarty like the plague, but I’m going to call that for what it is.

23

You are still using display logic, you’ve just altered the syntax and added a lot of overhead due to requiring another parser. I could add a million boolean checks like this in my code, and it would still be lighter-weight than a bloated regular expression based parser.

This is a rather poor, biased example because you used foresight (which in your example would be unknown to you at the time of writing) in your template code. An equivalent would be this:


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

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

That, semantically, is the same thing. So now requirements change, and you have to go back and replace all your tags with the new <logged_in_and_verified_user> (etc) so that the semantics are right. Same amount of find and replace.

24

There are always pros and cons with Smarty.
I too had severe pains converting templates and php codes from Smarty 2.xx to 3.xx.

But once comfortable how to use the template engine correctly, all goes normal.
Even the manual had given the guest book example wrongly. The Smarty object has never any reason to extend to create another object. Whatever complex be the page design be, single and even unextended Smarty works pretty well.

Hasin who wrote a book on Smarty too later has a different views to the Template Engine. But, Wikipedia has listed Smarty as one of the well featured template engine, in its [url=http://en.wikipedia.org/wiki/Template_engine_(web)#Comparison]comparison list

But it is true that large projects have already used at least one kind of template/rendering system. If not Smarty, you can choose others.

I have found it as one the best tool. The new release as several things improved.

25

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.

This is a rather poor, biased example because you used foresight (which in your example would be unknown to you at the time of writing) in your template code. An equivalent would be this:


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

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

That, semantically, is the same thing. So now requirements change, and you have to go back and replace all your tags with the new <logged_in_and_verified_user> (etc) so that the semantics are right. Same amount of find and replace.

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/simpletest/etc.

26

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?

27

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:

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.

28

  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.

29

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

30

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.

31

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

32
Off Topic:

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

33

Then become 100% :slight_smile:

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…

34

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.

35

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.

36

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.

37

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

38

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

39

On the server… in php… which this entire thread is about :stuck_out_tongue:

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.

40

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?