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 ...
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 e.g. <?= ... ?>
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.