In this note, I would like to show some new features of the incoming Open Power Template 2.1. The new branch, which is currently under development, will bring many new tools and improvements to the template language syntax and the library API. Some of them are already implemented, but there is still a lot of work to do. It is hard to say when it is going to be released, but I'll do my best, so that you would not have to wait another year for it.

Welcome back after a short break. Although there were no summaries in the last month, Invenzzia projects are still active and maintained. We have released two new versions in June, and now we are reaching the moment of releasing... the first stable version of Open Power Template 2! Stay with us and read more about the progress and the current status of the projects.

Welcome to the third episode of the Invenzzia Summaries. Today we will make a small celebration of the 100th revision to the OPL repository, as well as take a closer look at the recently implemented features, such as PHAR support, caching interface and the improved autoloader.

One of the goals in the OPL project is not only to provide a set of great libraries, but also teach the popular PHP software, how to use them. Currently, lots of applications are designed with the help of frameworks which often provide their own solutions. It is obvious that the users do not want to deal with all the integration stuff, especially if the library is in fact a replacement for a whole part of the framework. This situation perfectly suits to Open Power Template that is rather a presentation layer framework than just a simple template engine. Currently, the programmers may already use OPT in Kohana Framework thanks to the efforts of Damian Nowak who prepared a nice port. And now, we would like the announcement of the Zend Framework port that will be released soon.

Merry Christmas everyone! We've had a small delay with OPT 2.0.0-beta1 concerning SVN problems, but they seem to be solved. After the Christmas, we are planning to make important changes in OPL repository layout and everybody whose scripts depend on checking out should upgrade their paths. It is connected with introducing the independent development cycles for each library. The details can be found below.

I'm currently working on a project written in Zend Framework and while trying to secure sessions, I noticed that this utility does not have any class that collects everything about the visitor and the request. The problem is quite serious, as many values in $_SERVER depend on the installed server software, PHP mode (module, CGI, FastCGI...) and many other things. This means that the scripts should not rely on them without a proper processing, because it can even crash whole website after the software change (I experienced it not so long ago). Thankfully, I noticed that in the old OPF code, I have a class called opfVisit that does this job. Now it's a part of the new Open Power Classes project :).

Together with eXtreme, we work hard to make the first release available as soon as possible and we are quite close now. This is a perfect opportunity to tell something more about this project, which should be appreciated by those programmers who write their own scripts and libraries and look for a smart tool to make a documentation. The idea to write TypeFriendly was born in my head after I failed to add some necessary things to the XSLT sheets for DocBook. The PHP manual shows, what could be done with it (syntax coloring, lots of different formats, enormous amount of tags), but don't become too happy too fast. To achieve similar effects, we need weeks of coding and we must also fight against the portability. In fact, I'd rather use those weeks to write something more useful and friendly.

I've found a new entry on the bugtracker recently. The author informed that he gets "Nesting level too deep - recursive dependency" error while running the development examples provided by the newest OPTv2 dev version. I looked at it deeper and found out that he lowered the default nesting level limit 4 times from 64 to just 16. Obviously, this is a quite drastic change and would affect not only OPT, but many other scripts as well. However, I think it is time to take a look at the OPT issues concerning the requirements, because several of them needs a deeper explaination.