The incoming Open Power Template 2.1 will have a new, more powerful expression parser. Basically speaking, expressions are those pieces of language that evaluate something, producing a value, i.e. variables and operators. Both OPT 1.1 and 2.0 use a nice, manually-written parser that compiles them to a PHP code, validating their syntax and performing some extra transformations. While it works well, I think I reached the end of possible ways to extend it. It would be simply too complicated to implement new features to it, so I decided I must rewrite it into a formal grammar. Today, the main works on it are finished.

Finally, after a 1.5 years of the development process, we managed to release the first stable version of Open Power Template. The road was very long but I hope that it was worth it. In this short entry, I'd like to make a small introduction to the project history for you, as it is quite interesting and could give some clue, how this all began.

It's true, the new beta version of Open Power Template is available to download. It was planned to be released a week ago, but because of problems with SVN I didn't manage to do that (again, but hopefully for the last time). This is mostly a bugfix release, but there are some small improvements and changes in the component API, which was not documented then. The changes are not too big and were quite necessary to be introduced.

Somewhere in the middle of November 2007, I wrote the first (working!) lines of the Open Power Template 2.0.0 source code. After a year of hard work, I've already uploaded a revision that finally gives you all the invented features implemented. For that time, OPTv2 grew and changed its shape. The first development releases resembled OPT 1.1.x when it comes to API and some features. They were just ported to the new XML compiler. Nowadays, OPT is a totally different library. It is much more modularized and designed to make the integration with frameworks easier. There is still a lot to do. The incoming release will be the last one with the "-dev" prefix, and in the next few weeks, the beta versions will appear, then Release Candidates and at last, the first stable release.

The new development version became available a bit later that I planned, but on the other hand, I managed to add much more new things. The DTD issue is solved, as well as XML prologs, CDATA support and code escaping. The expression compiler is done and the programmers may use now brand new component implementation. This is a significant step towards the first beta release and the end is closer than further. There are only a few instructions to code, the rest is almost completed and works. The compiler, programmers' API and most of the stuff also works. I think of making the first real tests on my home website and creating the Open Power Forms library compatible with the new OPT.

The result of the latest works on the OPT source code is complete opt.class.php file which contains (as some of the readers may know) the main parser class. I must admit that this file was more demanding that the compiler. In the second case we can afford with quite a lot. Just an idea for the algorithm and prediction if and how it will influence the rest of the code. In the case of the main class, we must pay attention to the performance. It must contain everything that is run permanently and it must be fast and small. But the number of features is getting bigger and bigger.

The website now has the "Download" page. In it, you can find a new development version of Open Power Template. It also contains a simple script "docgen" which we use for automated generation of the DocBook manuals. The new development versions should appear now much more often than before. In case of many new features, they might appear even every 2-3 days. The reason why this was impossible in the past was the time. The process was not automated and it takes a while to prepare such archive (for example - it takes a couple of hours to publish new OPT 1.x version on the Internet).

The last project I've created using Open Power Forms, shown some weaknesses of the current form implementation. There were some forms allowing a mass addition of many records in the following way: a table, in the columns the following fields: Name, Surname, PESEL number, etc. The numer of rows was 30, so the user is able to add 30 people to the database with one form. The adaptation of the map() method to my problem was not too hard; in fact it seemed that opfArrayContainer solved everything. But then the form renderer connected with Open Power Template went off.