Why do almost all PHP framework use "<?php echo ... ?>"_问答_开发者

The PHP short tag <?= $var ?> has been deprecated for a while.
Almost all PHP frameworks use the long form <?php echo $var ?> (e.g., symphony, Yii, Kohana)
Smarty is a famous PHP template engine which supports a shorter form {$var}
Template engines (like Smarty) are easier for web designer
- Editing a template shows {$var} instead of showing nothing (because of <..>)
- Shorter syntax (less typing especially when <> are on the same key on some keyboard layout)
- The templates are pre-compiled and cached giving nearly the same performances

All those points make me wonder, why do all framework seem to use the super long PHP syntax? Is there a strong point of not using a template engine like Smarty (except the small overhead)?

The thing about PHP is that it already is a templating language.

Smarty, as nice as it is, is added overhead. If you don't have a good reason to use it, then why would you? People who use backend frameworks are developers who are already familiar with PHP, so there's no reason to make them use a templating engine with a new syntax to learn on top of it.

Most frameworks are flexible enough that adding a template engine doesn't take much work. If a framework was built that forced you to use Smarty, then it's going to be less popular, because the framework itself would be less flexible.

In regards to the "long syntax", no framework is going to hang their hat on a deprecated syntax with security issues. It can be left up to the user of the framework if they want to use it or not (which no one should be these days), but building a core framework around short tags makes it less portable.

I don't know that I would call <?php print $foo; ?> "super long syntax."

The fact is that short-tags aren't always enabled on servers, whereas the standard default typically is. It's safer going that route.

Template engines like Smarty add an additional layer of processing that is not needed - they are mostly bloatware. They usually add too much additional processing for what amounts to syntactic sugar. Using a template engine when full PHP tags are available is like wearing shackles - it becomes another language with it's own quirks to learn in order to accomplish the same thing with regular PHP.

In my experience I've rarely seen a non-programmer fully or easily utilize a template engine. Take these two instances:

Smarty:

<select>
{foreach from=$k item=v}
 <option value="{$v.value|escape:'html'}">{$v.label|escape:'html'}</option>
{/foreach}
</select>

PHP:

<select>
<?php foreach ($k as $v) { ?>
 <option value="<?php echo htmlentities($v['value']); ?>"><?php echo htmlentities($v['label']); ?></option>
<?php } ?>
</select>

Now, the Smarty syntax may be slightly cleaner - but honestly, is anyone except a programmer going to be able work with either code set comfortably? Template engines add an extra layer of processing/logic without offering any major benefits.

Here's what Fabien Potencier of the Symfony framework has to say about templating engines:

Why do people still think PHP is a templating engine? Sure enough, PHP started its life as a template language, but it did not evolve like one in the recent years. If you think PHP is still a template language, can you give me just one recent change in the PHP language which enhanced PHP as a template language? I cannot think of one.

He also describes the features that he looks for in a templating language:

Concision

Template oriented syntax

Reusability

Security

Sandbox mode

As well as some of the features that make his favorite templating language Twig stand out:

Native template inheritance (templates are compiled as classes);

Solid automatic auto-escaping (with no associated runtime overhead as everything is done during compilation);

Very secure sandbox mode (white-list the tags, filters, and methods that can be used in templates);

Great extensibility: you override everything, even the core features, by bundling your own tags and filters as an extension; but you can also manipulate the AST (Abstract Syntax Tree) before compilation. By leveraging this possibilities, you can even create your own DSL (Domain Specific Language), targeted at your application.

In the comments of the article, he says that, "It will probably be part of Symfony 2. But I first need some community feedback."

Read the full article to get his whole argument in favor of templating systems.

There are some reasons:

They are to be deprecated from future versions of php due to security concerns.
Some hosts disable them.

More:

Are PHP short tags acceptable to use?

They're not recommended because it's a PITA if you ever have to move your code to a server where it's not supported (and you can't enable it). As you say, lots of shared hosts do support shorttags but "lots" isn't all of them. If you want to share your scripts, it's best to use the full syntax.

I agree that
I don't buy readability as a reason at all. Most serious developers have the option of syntax highlighting available to them.

More

http://terrychay.com/article/short_open_tag.shtml

Short open tags are not deprecated and they will also not be removed in PHP6.

[PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
[PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
[PHP-DEV] short_open_tag
Request for Comments: Improved short tags for templating

The linked articles also contain lots of useful information about the topic.

Quoting Rasmus Lerdorf (3rd link):

Most of the arguments I have seen are basically saying <? is evil and it shouldn't even exist, but that isn't the current question. It does exist, and we aren't removing it, so the only real argument here is the WTF factor introduced by code that is able to enabled or disable these tags on the fly. That's the one and only valid argument I have seen. Whether or not PHP code can be validated with xmllint and whether or not <? is valid xml, which it obviously isn't, is completely beside the point. We all know that when you use <? you are not XML-compliant. And for the vast majority that's ok. […]

My view is that people want templating. As much as I hate the concept, and have always been very vocal about that, people want simpler templating tags. They will even go as far as parsing files and generating PHP code on every single request in order to use {blah} instead of <?php blah() ?>. The fact that people are willing to take an order of magnitude performance hit for syntactic sugar is baffling to me, but just look at all the templating systems out there. And yes, I know there are other reasons to use templating such as restricting the feature set for untrusted template writers, etc. but you'd be surprised how many people just want to type less and have their tags be prettier. Getting these folks to switch to <?blah()?> is a win for performance and sanity in my book. Yes, it isn't a full victory, but it is still a win.

Personally, I try to avoid templating systems as I find regular PHP syntax much easier to use as a templating language that reinvents what PHP can do out of the box. With the addition of ViewHelpers, any designer shouldn't have too much trouble using regular syntax. Actually, I always found the argument, Template engines (like Smarty) are easier for web designer pretty belittleing. The verbose PHP syntax might not be appealing aesthetically, but any half-brain can learn it.

Because they don't want to include a library as huge as Smarty to make their templates a few characters shorter.

In addition to the other answers there are a couple of things that make Smarty (and similar template engines) problematic.

The first is that you need to escape some characters in your template if you're going to put javascript in it. If your javascript is dynamically created by PHP, it gets even worse; the readability of that code goes down drastically.

The second and most important is that when you're working in a decent OO framework Smarty will severely decrease the functionality of your code. When using PHP as your template engine you can use $this within your template to call methods in the controller that's parsing the template. Not only that, but you get access to all the methods that controller has inherited. With smarty you lose this entire functionality because $this no longer refers to your controller. In essence, instead of accessing your entire framework from your template, you only have access to Smarty's limited functionality.