Invenzzia... in English - Tag - releases

Open Power Template 2.1 almost finished

Zyx — Mon, 01 Nov 2010 20:06:00 +0100

Works on Open Power Template 2.1, the greatly extended successor of OPT 2.0 are almost finished. I know it was a long year, but finally we reach a point where we can plan our next steps and think, what to do next. The current package will be soon packed as OPT 2.1-BETA2, and the remaining functionality will appear as a part of the first Release Candidate.

What is not finished yet?

Basically speaking, there are three things left to do:

Implement Opt_Format_NestedTree data format for opt:tree instruction which will allow to push a nested array in order to render a valid HTML tree.
Finish the migration module which will allow to run OPT 2.0 templates and convert them on-the-fly to the new release.
Finish the support for opt:append and opt:prepend tags in opt:switch instruction in order to make possible to add dynamic attributes in this way.

The list of implemented features and changes is really impressive. Just a quick look at the code repositories of 2.0 and 2.1 branch can tell us that OPT 2.1 is another revolution, with many clean-ups and improvements.

Further release process

Unfortunately, in order to see a stable release of OPT 2.1, we still need some time. Although I test the new branch in different situations and environments, including real projects, the debugging process is not finished yet. The test code coverage is not as high as I'd like and it needs to change. Another critical issue is the new documentation, where the progress is very low.

Plans

I'll do my best to release OPT 2.1 stable before February 2010, because that month I expect to start works on Open Power Template 3. Lots of things have changed in the PHP world last time, especially where it comes to the frameworks and the application design theory. Open Power Libs 2 was a pioneer in several library design concepts, such as universal autoloader or the need for a small, unified core, but its internal structure and design does not meet current code quality standards. Open Power Template 2 suffers from the same issue. Other development teams from such projects, as Doctrine and Symfony, have already started works on improving them, and so must we.

So, what is the exact plan for Open Power Template and Open Power Libs 3? The overall project philosophy will remain the same, which means that if you already know how to use OPT 2.x, you should not have any problems with 3.x. I plan not to make significant changes to the template language, because it has already been polished in the current releases. We will still use good, old XML syntax, sections, switches, components, etc. The only key goal is to make the language fully secure. It means that from the template level, it should not be possible to cause neither PHP fatal, parse error nor access any forbidden function and class.

The main revolution will take place in the library programming interface. The OPL core will use some third party components:

Symfony 2 Event Dispatcher
Symfony 2 Console

Furthermore, there will be fewer components:

the universal autoloader,
configuration object,
error handler,
debugging interface.

Open Power Template 3 public API will be more compact. I very like the job the guys from Doctrine did in Doctrine 2 project and I'd like to do the same with my library. The API should be simple and intuitive, there should be no magic, and the dependency injection should be done explicitely. The registry and the static stuff will be thrown away.

I'd also like to make the compiler itself completely independent from the standard public API which should allow to use it without it. Its API will be also polished, especially when it comes to data formats, instructions and extending. Here, the following things are going to be implemented:

data formats will be composed of simple PHP interfaces, which should simplify the entire API and ease the data format building.
the compiler will make a good use of the reflection mechanism to find out what a particular class provides.
function packages will simplify installing new template function sets.
the compiler internals will be separated from the concrete template language implementation - all the languages, including the default one, will be installed by registering a new language class object in the compiler.

The expected result is simple: the most advanced, the most powerful, the fastest, the one, where writing templates is also the fastest, and the greatest template engine in the world. Ever.

Open Power Template 2.1-beta1

Zyx — Sat, 04 Sep 2010 10:08:00 +0200

I'm pleased to inform that after a year of work, Open Power Template 2.1 goes into a beta testing phase. As you might expect, the new branch is a revolutionary evolution. Although it was born in pain, the new development stage is a fact. In this post I'd like to describe briefly the changes and new stuff that can be found there. Meanwhile, if you look for stable releases, OPT 2.0.6 is also available to download. It fixes four bugs.

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.

Open Power Template 2.0.0 is ready!

Zyx — Tue, 14 Jul 2009 09:14:00 +0200

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.

Open Power Template is a quite old project, lasting for almost five years now. The development started in November 2004, as a small template engine for the open-source discussion board project called Open Power Board. The library was a creative variation of the Smarty engine, and I was the right person in the team to write it, as I was writing small template engines much earlier and had some experience in this area. Fortunately or not, the OpenPB project failed and my library was the only which survived the crash. After some huge code revisions, I released the first stable version, 1.0.0 in July 2006, three years ago. At the first sight, the template engine was quite similar to Smarty, especially because it used curly brackets, too. However, we could find there some ideas that were later improved and featured in the 2.0 branch. OPT 1.0.0 contained:

Sections
Components
Snippets (under different name)
I18n support

The 1.1 branch brought the pagination support and tree rendering instruction. The template engine did not understand the document structure, but the parser used some ideas taken from XML parsers. For example, it constructed a node tree for the content similar to DOM, and the nodes were instruction tags and the text content. Furthermore, there was a feature called XML Compatibility Mode which replaced the curly brackets with XML-like instruction delimiters. However, this was only a visual change.

Early in 2007, after some talks with the users, I started thinking about using a real XML parser in Open Power Template. On my blog, I published a note dated to April 19, where I suggested that a compiler with an XML parser could be written, as an extra compiler for the project. It did not mean that the works began then, as I was beginning my studies on AGH University in Cracow and had little time to deal with it, too. The first lines of code were written about seven months later, in November. On November 23, I wrote on my blog that the parser loaded the first XML document into memory, and a couple of days later it compiled its first (very simple) template.

OPT was a really productive project. Soon, I realized, that the old infrastructure from OpenPB used so far is crappy and unreliable which led to the formation of Invenzzia Group in January. You may ask where the name came from. We were thinking about it very long, and the further, the more stupid ideas were coming into our minds. As I was fascinated with linguistics and artifical (constructed) languages, we opened the dictionary of one of my languages, Ferrinti with the word: invenzzia - invention. By the way, it has nothing to do with Polish language, where the word for invention is wynalazek and inwencja means something completely different.

A couple of months later, I was becoming more and more annoyed with DocBook, especially because of the lack of any simple-in-use framework for generating user manuals and documentations from them. Because I did not want to deal with various XML parsers, incompatibility issues between Windows, Linux and everything else, I decided to write a completely new tool in PHP. This was the second project inspired by Open Power Template and it is known now as TypeFriendly. At the same time, we closed the 1.1 branch of OPT, to focus on the other projects. In July, the branch was actually rewritten from scratch, introducing a completely new API that had nothing to do with the earlier versions, as it was using many new features, such as autoloading, or better use of exceptions. Furthermore, I removed the explicit recursion from the compiler that produced very serious trouble due to the PHP stack limitations. Precisely after a year, on November 23, 2008, Invenzzia Group released the last 2.0-DEV version with actually all the planned features finished and began the beta-tests and the debugging process. After deep analysis, some parts of the code were rewritten once more (notably sections and data formats), providing a more stable and flexible source code, and many other features were widely tested both with unit tests and the real projects.

In March, I published the first revision of the Zend Framework port on our SVN. The community created a port for Kohana framework a couple of months earlier. I started also thinking about the tutorials. In the last few days, we managed to finish the user manual and the huge tutorial A photo gallery with Doctrine and Open Power Template, and we decided that we are ready to release the first stable version. And here we are!

Invenzzia Summary #5

Zyx — Wed, 08 Jul 2009 13:28:00 +0200

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.

Open Power Template 2

The project is actually finished and we are expecting to deal with all the formalities in the next few days. There is only one chapter missing in the user documentation and if you would like to check the code right now, you can find it on our Subversion repository. So, what would take so long? The answer is simple: the tutorials. Since April, I have been working on a huge article entitled "A photogallery with Doctrine and Open Power Template 2.0" showing the process of writing a web gallery using the libraries mentioned in the title. Furthermore, it is going to be available in two language versions: Polish and English. We have to finish the translation and rewrite it into Markdown, so that it could be published on Invenzzia. Anyway, the development process is over and now we can focus on implementing the new features and the new libraries.

TypeFriendly 0.1.2

A couple of weeks ago, we released TypeFriendly 0.1.2 with many new features, such as appendix support and tag manager. Since then, there were new commits and new works-in-progress. eXtreme improves the layout of the chapter headers, there are expected new tags and fixed some minor bugs.

What's next?

I plan to finish the caching system for OPT that will be distributed with Open Power Classes, and start developing the source code of long-awaited Open Power Forms. We have an idea, what we want to get and how to achieve the goals.

Open Power Template 2.0-RC1

Zyx — Tue, 12 May 2009 13:06:00 +0200

Finally, the first Release Candidate of Open Power Template is available to download, after 4 months of testing and implementing the remaining features. The library seems to be completed and stable enough for both development and production environments. Of course, there is still a small possibility that a fatal bug will be found, but I do not think this will happen, as there are lots of unit tests present and the code has been checked with two real-world web applications.

Where to download?

Of course, from our website: Invenzzia. There are available the ordinary packages, and moreover, for the first time we publish the PHAR-s. PHAR means PHP ARchive - it is a package of executable PHP code that works much like JAR-s in Java. It is going to become a part of the official PHP release since 5.3.0 version. Unfortunately, our web system is not prepared to publish so many different files in one branch, so I publish the links right here till the problem will be solved:

The packages contain two PHAR-s: for OPL and OPT, license texts and the README. They do not include the documentation.

What now?

Well, Release Candidate does not mean the end. There is also the stable release, and lots of plans for the 2.1 branch. However, for some time the development process of OPT will slow down, as there are some other projects that need our urgent attention. First of all, we have all the resources for the programmers: tutorials, tips, case studies etc. Open Power Template brings a completely new philosophy of creating the presentation layer and there must be good articles available in order to show, how to make a good use of it. Moreover, there are next libraries on the way: Open Power Classes, Open Power Forms and the Zend Framework port.

Conclusion

At the end, we would like to thank all the current users of the library, especially those ones who have helped us with the development process. These projects are created for you.

Invenzzia Summary #2

Zyx — Tue, 28 Apr 2009 14:22:00 +0200

Invenzzia Summaries are the way to inform about what's going on in Invenzzia and its open-source projects. In the second episode we will talk about incoming OPT 2.0-RC1, OPL port for Zend Framework and the incoming first bigger practical tutorial about OPT.

OPT 2.0-RC1

The source code of OPT is almost ready to publish the Release Candidate 1. The remaining issues concern the user manual and the examples that should be included now in some form. In the last few days, the source code itself was enriched with:

The unit tests for the template functions.
The final version of the caching API.
Fixes of the bugs found in the Beta3 release.

There is a small change in the previously accepted API. The Opt_Component_Interface::setDatasource() method does not require the reference now which allows to read the data from objects and any other forms of expressions. We are sorry for this oversight and the necessity of updating your component APIs.

Recently fixed bugs

The bugs fixed in the last days include:

(OPT) - bug #81 - The opt:tree instruction did not perform the error checking, which could be used to produce the invalid output code if the depth parameter was not set properly. Currently, the depth does not have to start with 0, and each raise above the initial depth is reported with an exception.
(OPT) - bug #80 - The expression parser did not capture the single occurences of the apostrophes. The output code was not affected, so this was not a critical problem, but now the parser throws an exception in this situation.
(OPT) - not reported - the defined components were generating invalid PHP code.
(OPT) - not reported - the output systems used invalid constant indicating the XML mode.
(TypeFriendly) - bug #79 - If the header section in the source document was not ended with a valid section delimiter, the script was going into the infinite loop.
(ZFPort) - not reported - the components attempted to read the CSS classes for the invalid fields from wrong template variables.
(ZFPort) - not reported - fixed the implementation of url() template function.
(ZFPort) - not reported - fixed the problem with Invenzzia_Controller_Response_Http and flushing the output buffer which caused to produce the "1" string in the output.
(ZFPort) - not reported - some of the overloaded methods had wrong prototypes which caused E_STRICT messages.

OPL port for Zend Framework

Recently, the port has been extended with the cache wrapper that allows to use the Zend_Cache component to cache the OPT views using the new OPT caching interface. Moreover, during April we have removed some annoying bugs in the code and tested the port in the real project. It works nice, but still needs some extra functionality. We are going to start the pagination support soon.

OPT tutorial

OPT provides the end users a lot of features, so nobody should be suprised that there is a need to write good practical tutorials for this library. In the last weeks, I have been working on the article entitled 'A photo gallery with Doctrine and OPT'. It shows the basic usage of Open Power Template and Doctrine library while writing a simple photo gallery script. The article will be available in two language versions: English and Polish and distributed under the Creative Commons license together with the accompanying, ready-to-run source code. Currently, the article is on the translation stage and will be published soon after the OPT 2.0-RC1 appearance.

Conclusion

We are very happy that the development stage of Open Power Template finally reaches the happy end. We know it was very long (a year and five months), but there was a lot of work to do. We are not going to stop here. Some of you may have probably noticed that the bugtacker is full of TODO tickets for the 2.1 branch which are going to bring even greater revolution in the template engine world.

Zend Framework port is available!

Zyx — Wed, 25 Mar 2009 15:12:00 +0100

I've recently uploaded the first revision of Open Power Libs port for Zend Framework to our SVN repositories and it is available there for public audience. The port is not completed yet, but the basic functionality is present and seems to work. I encourage everyone to test it and submit suggestions or noticed bugs. The package includes a test ZF application, and the source code is well-commented. I'll put some extra information on wiki soon, as well as set up the "real" user manual.

How to obtain?

If you have a SVN client, you can download it like any other Invenzzia project:

svn co http://svn.invenzzia.org/svn/opl4zf/trunk

Note that you must also download Zend Framework and OPL.

OPT 2.0-beta2

Zyx — Sat, 21 Feb 2009 09:22:00 +0100

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.

The changes in the component and block API:

setOptInstance() became setView and takes the current Opt_View object as an argument. Now the components and blocks can refer to the template variables.
createAttributes() became manageAttributes(), and moreover, the semantics has been changed. The new method takes an array of tag attribute values and returns the modified version. OPT translates it to the valid XML attribute list.

The tutorials can be found in the documentation. Another improvement are the get() and getGlobal() methods in Opt_View that allow to read the template variable values from the view object.

The things that need to be done now are:

To check the caching port interface.
To test several rarely-used compiler API features.
To check, whether all the features mentioned in the documentation are implemented and vice versa.
To fix more bugs :).

By the way, it is possible that in a few next days, there will be PHAR files with the beta2 available to download for use with PHP 5.3.

The library can be downloaded from our file repositories and the English documentation can be found here.

OPT 2.0.0-beta1 released

Zyx — Tue, 06 Jan 2009 22:45:00 +0100

Well, after many adventures with SVN and recently discovered problems with XML prologs and DTD I finally managed to release the first beta version of Open Power Template. From now, we are going to focus on removing as many bugs and problems as possible and we need here your help. Furthermore, we also need to complete the English manual, which is quite big now, but still does not explain some issues.

I hope the library will mature soon, because I want to start works on next libraries: Open Power Forms and Open Power Classes. Thankfully, our quite small community is quite active. Recently, Nowaker informed me he prepared a port for Kohana framework and he is going to release it, soon. As eXtreme will complete the new Invenzzia website, we will be able to put such add-ons in one place, as well as tutorials and sample projects.

The library can be found in our download sites. The packages contain English manual, which is also available on-line.

One year of hard work

Zyx — Thu, 20 Nov 2008 18:59:00 +0100

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.

I still get questions, why the hell I'm writing "yet another template engine if PHP is a template language itself". In my opinion, it is not PHP which is so good. The template engines are simply too bad, and unsually offer some control structures taken from PHP, variables, put them into different syntax and that's all. Why the hell someone would like to use such stuff if PHP gives him the same things plus object oriented programming to make the code more reusable. But take a look at another issue. Do you think that imperative languages, like PHP, are comfortable enough to be good languages to write, in fact, simple templates? In my opinion, the language that required to be taught, how to display a nested list and escape script data every time we want it is a mistake in this place. Such languages are created to express fast and advanced algorithms, where we need the full control over the process, not to take some data from the script and put them in a string. Yes, we can modularize them with loads of classes, interfaces etc. but is it still a comfortable way and a good use of OOP? In my opinion - no.

What give us new languages

When people noticed that writing in assembler is too complicated, they invented Fortran and Lisp, the first two high-level programming languages. They allowed to express the same algorithms and calculations in more human-readable form. Later, they invented C and C++, two general-purpose imperative languages. As the WWW appeared on the Internet, another group of people noticed that existing programming languages are too complicated to make dynamic websites. Would you like to deal with memory allocation while writing a CMS? The computers are nowadays faster and faster, and people noticed that sometimes it is much better to use simpler language designed for certain tasks at a cost of performance. In the template engines, the rule is similar. PHP in its current shape was never a good template language, so we try to create something different that simplify this process. And how to achieve this? We have to change the programming paradigm. As we design the new programming language, we can do almost everything with it and add features that are impossible in another language.

OPT template language

The basis of OPT template language is XML. Unlike PHP, OPT understands entire structure of the XHTML code in the templates and checks its syntax before we see something in the browser. All the language constructs are allowed to manipulate the code in the way that is impossible in PHP, using an interface similar to DOM. They can add new attributes, create tags, and the compiler prevents them from generating invalid output. Moreover, I wanted to get rid of programming in the templates, so I designed the control structures in a declarative style. An example of such declarative language is SQL, where you describe, what data you want to have and the database engine decides, how to find them. Here, you simply inform, what you want to see, and the template compiler provides you the implementation. Below, we have an example of displaying a hierarchical list of categories (a category tree):

xml
<opt:tree name="categories">
 	<opt:list><ul><opt:content /></ul></opt:list> <!-- 1 -->
  	<opt:node><li>{$categories.title} <opt:content /></li></opt:node> <!-- 2 -->
  	<opt:treeelse><p>Sorry, there are no categories in the system.</p></opt:treeelse> <!-- 3 -->
</opt:tree>

Do you see here any tree rendering algorithm? We have only elegant definitions, how a flat list looks like (1), how a node looks like (2) what what to show if there are no categories. We even know nothing about the data format. The template would not tell us whether the category tree must be provided as a big object or an array, and what are the details of its structure. As OPT provides a complete declarative programming model, similar solutions can be found almost everywhere in OPT. It really works. A couple of days ago I started writing a small website for my friend. Thanks to OPT, I managed to write all the presentation layer in 15 minutes. The fact that I did not have a working script yet did not concern me. I knew that OPT would do everything for me once I finally decide, where the script would return arrays, where objects, and what they would really be. I do not worry about code refactoring, because the templates remain untouched. Once I make a critical change, I simply recompile the templates and that's all. Try to achieve this in pure PHP or Smarty!

OPT language features:

True XML parser with configurable level of standard-compliance (from strict mode to quirks mode, where everything that is not directly parsed by OPT is a static text).
Variables are data format independent - the data structures are chosen during the compilation thanks to information from the PHP script.
Two complete models of handling modular templates: by including and by template inheritance (also dynamic).
Intuitive support for nested lists
Smart and semi-automatic data escaping.
Additional useful instructions to create cyclically changed values or to add separators between elements.
XML manipulation instructions.
Support for runtime instructions: blocks and components that are designed especially to deal with HTML forms.
Code reusability: write once, use everywhere.
Set of data manipulation and aggregation functions.
Support for i18n.
A complete expression language designed especially for use with XML. It includes the complete PHP object access support.
A basic set of programming structures: conditions and loops, if they are really necessary.

What about the API?

OPT source code design resembles Zend Framework conventions, when it comes to the class/method naming and file structure. It is fully objective - the templates are represented in the script as view objects, where we can assign the script results to and set the data format. Once the view is fed with the data, we create an output object and order to render the view. OPT provides two default views: HTTP and Return. The first one sends the results to the browser and maintains the HTTP headers. The second one returns the generated code back to the script. Of couse everything is extendable: you can write new outputs, define new data formats, write new functions, components and even instructions with the powerful compiler API. The management of all this stuff is also simple, because there is a plugin system.

The templates can be loaded and stored everywhere thanks to PHP streams. All you have to do is to write a new stream wrapper and register it in PHP. The advantage of this solution is that the wrapper can be used with all the file access functions in your script, even with require and include. The output results can be cached, but this time OPT does not provide its own cache handler, allowing the frameworks to do their job. In order to help the programmers manage the templates, the debug console is provided that shows information about the current configuration, executed and compiled templates and the resources used to perform those tasks. The errors are handled with the exceptions and the default error handler provides extra context information with additional explainations, how to fix the problem and where to find the solutions.

Below, you can see a sample use of OPT in the scripts:

php
try
{
	$view = new Opt_View('template_file.tpl');		
	$view->foo = value;
		
	$out = new Opt_Output_Http;
	$out->setContentType(Opt_Output_Http::XHTML, 'utf-8'); // Content negotiation available!
	$out->render($view);
}
catch(Opt_Exception $e)
{
	Opt_Error_Handler($e);
}

However, OPT is not a standalone script. It is the first library in the Open Power Libs series. They share a common core with the basic core that provides the necessary features, like autoloader, configuration, plugin architecture, debugging issues and PHAR support.

Project status

As I mentioned in the excerpt, all the planned features are currently completed, but not fully tested yet. The code seems to work in all the common use cases, but lots of deeper interactions between various elements are a big unknown. At this time we are going to start beta tests that will take some time. Meanwhile, the following tasks are waiting:

To complete the English documentation.
To write the complete unit tests and support for PHAR-s.
To write tutorials, FAQ-s and sample codes for OPT.
To provide the initial add-ons: Unicode function set for the templates, complex port to Zend Framework and probably Kohana. In the near future we are going to provide the support for Symfony, too.

Moreover, the next OPL projects are going to be opened. Currently, we have already started works on Open Power Classes, a set of small PHP classes to deal with various useful stuff. Our next big goal is Open Power Forms - a complete form handling solution for your script that shows the real power of Open Power Template.

How to help?

In the next few days, OPT 2.0.0-dev8 should appear. The source code for this version is already available in SVN, but I want to finish some API reference translations. Test it and send us you opinions. If you think you found a bug, use the bugtracker and let us know about it. Do not be afraid to ask - our community is still quite small, but the Invenzzia team is very helpful and does its best to help you deal with the coding problems.

To sum up

I know this post is full of propaganda stuff, but on this blog, it has not been announced so far and I think it is necessary to show, what this project really is and why we are writing it. Open Power Template is something more that just a template engine - it is probably the first presentation layer framework designed as a complex solution, and in addition - fast. I hope you'll enjoy it. Many people managed to enjoy OPT 1.1.x, and incoming 2.0.0 is simply much better.

Update: OPT 2.0.0-dev8 is available to download. The English manual can be found here.

TypeFriendly 0.1.0 released

Zyx — Wed, 23 Jul 2008 10:34:00 +0200

At last, the translation of the manual into English is complete and the source code has been already released as the first version of TypeFriendly, the documentation generator. In is available in Files on the main site. The user manual is provided in the source form and it works also as an example, so please do not worry that something is missing. All the necessary information to build the HTML version can be found in /info/README.txt file. All you need is to type one command in the system console. The on-line documentation will be available soon, as we are preparing new website. To get more information about TypeFriendly, take a look at the previous note.