在Lithium中关闭PHP标签

Question

As you know most PHP sources deprecated inserting closing tag, but I wonder why in Lithium documentation , it is encouraged to include a closing PHP tag? Is there any rational reason for that? Beside that there is some other obsolete style in its documentation. Is Lithium an active project?

Update: Even opening php tag in a file that contains only PHP seems redundant and we include it because currently we have to do that, (if there was a standard file extension for files that have only php code no need for opening tag remained), but more odd is that somebodies even say that we should include a closing tag!

Answer 1

Omitting closing tags is sloppy.

The only excuse anyone ever gives for doing it is that you might accidentally leave some trailing whitespace, causing headers to be sent prematurely. Here's why this justification is completely bogus:

1. If you have Xdebug installed (and if you don't, you have bigger problems), it'll tell you exactly where your output has started if you try to write a header
2. I find this kind of behavior symptomatic of an overall lack of attention to detail; chances are, if you got this wrong, there are other things wrong with your code as well (or you have a shitty/poorly-configured editor)
3. This is completely negated by good QA tooling: we have li3_quality , which is a comprehensive code quality validator

Essentially, people are justifying sloppiness with the worst form of laziness.

If you browse through Lithium's coding standard, you'll notice the high level of attention paid to symmetry. Everything in the coding standard is symmetrical. Including open/close tags. Doing so is never a problem for us, because we have good QA tooling.

Answer 2

Lithium Coding Standards

The link reffered to in the question ... Coding Standards ... is just that, what the Lithium devs believe are the best coding standards for their project. I personally agree that a closing tag is preferable.

While the PHP docs say it's "preferable" to not use the close tag if it's "pure" PHP code (mostly so you don't accidental add white space or something after it) a simple way to avoid that is to not do it in the first place. I prefer leaving in the tag so that ...

• The code looks more uniform
• To insure server compatibility
• For better support of color-coding etc in text editors

This is also somewhat a misunderstanding of how Lithium works ... the examples given are for files that act as Controllers , Models , etc. These files are for the most part not directly accessed by end user requests like the Views are (well for lack of a simpler way to explain it.)

Is Lithium an active project?

As for if Lithium is an "active" project I suggest referring to their ...

• git repo https://github.com/UnionOfRAD/lithium
• commit history: https://github.com/UnionOfRAD/lithium/graphs/commit-activity
• dev branch https://github.com/UnionOfRAD/lithium/tree/dev
• dev commit history https://github.com/UnionOfRAD/lithium/commits/dev

As of this post the last dev branch commit was 10 hours ago.

Lithium's use of "short" tags ...

For the record, other examples in the Lithium doc's use the so called PHP "short" tags eg <?= ... ?> instead of: <?php ... ?> comes with an important caveat see the docs :

You might have noticed that the above example uses the short tag syntax to output the contents of a view variable. This syntax is a bit misleading, as Lithium does not depend on or use short tags: this output behavior works a bit differently from how it seems. When the view layer is rendered, each template is processed by a tokenizer before it is compiled into its final form. During this step something like this:

<?=$variable; ?>

Is translated into something like this:

<?php echo $h($variable); ?>

The $h() function you see used there escapes HTML. To make a long story short, this mechanism provides an easy way for you to make sure all dynamically-generated data is safely landing in your HTML template.

We highly recommend using the <?= ...; ?> <?= ...; ?> syntax in your views, as it aids greatly in hardening your application against cross-site scripting (and related) attack techniques.