Why so long?

There is no a single answer for this question. Personally, I like this one: because it's Open Power Template and it's made by me. Step by step, without a hurry, with proper amount of time to think and design the new features. Another thing are my computer science studies which do not let me give a bigger priority for this project. What is more, the library itself is so complex right now, that there begin to appear the problems like "well, it's great idea, but how to implement it in PHP?" I think that without a variety of new features in PHP 5.3, finishing OPT 2.1 would be impossible.

Changes

The exact description, what has changed and how to use it, can be found in README files appended to the package. Here, I'm just going to list them in order to show, how much has been done. The size of the source code is almost twice as large, as in OPT 2.0, and I don't mean here those parts that were present, but have been rewritten from scratch. Most of the new source code lies in the phpdoc comments and the template compiler. But let's get back to our list:

• Introducing the compatibility with PSR-0 class naming standard, with the exception to the namespace use.
• Exception system cleanup.
• New, simpler and faster autoloader compatible with PSR-0.
• New error handler.
• Changes in Opt_Caching_Interface
• Decomposition of the compiler which has become a true framework for writing any template language we want:
  • We can create new parsers.
  • We can create new expression engines.
  • We can install new expression modifiers.
  • We can add new node types to the OPT-XML internal representation.
• Added support for ambiguous instructions (np. opt:else) that are linked with concrete processors according to their context.
• Improved instruction API.
• Improved data format specifications.
• Improved compilation algorithm.
• Rewritten and optimized operations on OPT-XML tree.
• Brand-new LALR-grammar expression parser with new features, such as container constructors, named function arguments and compound operators.
• New parser based on XMLReader extension available.
• New instruction: opt:switch which is like sections for loops. (partially implemented)
• New, alternative syntax for opt:if.
• Long ifs, a feature that allows to put unconditional pieces of code between conditional opt:if branches.
• New instruction: opt:procedure to create procedures (an equivalent of snippets, but evaluated during the runtime).
• Snippets can take arguments.
• Actually, procedures can take them, too :).
• opt:root include replaced with a new instruction: opt:load.
• New section attribute: from.
• Alternative for opt:show: opt:body.
• Changed the way the expressions are deployed within HTML attributes.
• Improved instruction naming convention. Now all of them use opt:name-with-pauses style.
• Some instructions have got simplified and improved names.
• Data formats for tree rendering.
• opt:selector i opt:attribute are being rewritten to the API of opt:switch (to be implemented)
• Data formats for components and blocks. (to be implemented)
• Backward compatibility mode that allows to use OPT 2.0 templates without any changes, and can perform the full conversion (partially implemented)
• Command-line interface. (to be implemented)

And we have to remember that OPT 2.1 requires PHP 5.3 or newer and will not work on PHP 5.2.

Many users would also appreciate that OPT 2.1 will have a brand new user manual with different content structure.

Plans for the future

The plans for the future are very simple: to finish OPT 2.1 and start developing OPT 3.0 as soon as possible. OPT 3 will focus primarily on improving the library API, whereas there will be no bigger changes in the template language. The most important improvement will be the introduction of true type system and cascading data formats which were originally planned to appear in OPT 2.1. Perhaps, there will be some new instructions: maybe some meta-programming features, but here I'm not sure yet whether we actually need it.

Going back to the API issue, we should prepare for a big revolution here, because OPT 3 will be namespaces. More exact plans are:

• Simplification and improving the names of some interfaces.
• Throwing away the magic and unnecessary stuff from the programming interfaces.
• Improving the specialization of classes.
• Integration with various code foundations. The OPL core will be reduced - probably it will only offer an autoloader, debugging system and error handling, whereas the other functionality will be included from various third party libraries. The most probable candidates are Event Dispatcher, CLI and Template Component from Symfony.
• The compiler will be independent from the public classes.
• Automatic data format detection.
• External compilation service. The idea came by analyzing a question I received on PHPCon Poland: "Let's say we have a blogging system and give the users the opportunity to edit the templates. What would happen, if 100 of them modified their templates in the same time". Currently the answer is simple: the server would slow down for a moment due to 100 template compilations in the background. In OPT 3.0, the compiling service would be deployed somewhere else and process the compilation requests sequentially. The requests would be sent directly by the blog control panel.
• Make the template language secure for the script. I mean it will be impossible to cause a fatal error or gain access to some internal interfaces through the templates.

Summary

I'm satisfied there are quite a lot people who use Open Power Template. Developing this library is not a trivial task, but I think it is worth it. One thing that make me love template engines is the fact that we can put a megabyte of source code to them, people get shocked "oh man, this cow must be so slooow", but it turns out that this cow is often faster and more agile than pure PHP :).

There are only two problems that confuse me. OPT is an one-man project. The compiler is so complex that many people are simply afraid of discovering, what's going on right there. Even Invenzzia Group which makes a lot of good work with other libraries, does not help much with the compiler internals due to the lack of experience and understanding it.

Similar thing happens to the template language. Its biggest pro: flexibility and breaking the schemes is the biggest con, because it requires from the programmer to get used to it. We can get a real satisfaction from it, once we understand the project philosophy and break with the old thinking patterns which is not so easy.

In both cases, the necessary thing are tutorials. When it comes to the template language, the situation is not so bad, but people who would like to learn the compiler internals, have almost nothing, except a small "Hacker's guide" on the project wiki.

Anyway, the project is still under an active development and it has the future. I'm waiting for any suggestions and ideas which will help to make it better and better.