Invenzzia... in English

Invenzzia goes to github

Zyx — Wed, 26 May 2010 13:42:00 +0200

So far, our projects have been hosted with Subversion control system installed on our own servers. While it is quite convenient and we are not limited by resources, it causes some problems with authentication and simplifying access for users that wish to help us developing our projects. In the last days, we have been discussing on that and decided to switch to Git. In the near future, all the projects will migrate to Github which will become our official hosting platform. I hope it will make the collaboration much easier.

Note that one of our projects has already been ported to Github - TypeFriendly. The others, including OPL will migrate in the next weeks, as this requires from us some effort and time. Basically, we have some scripts that help us publishing new versions and they must be rewritten from SVN to Git.

New expression parser for OPT 2.1

Zyx — Sat, 23 Jan 2010 13:00:00 +0100

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.

Formal grammars

The new expression parser is defined using a formal grammar. It is a set of rules describing, how the tokens, the smallest units of the language, can be connected to produce something useful. In the example below, we have produced a simple grammar that allows adding and multiplying numbers:

expr -> expr PLUS expr
expr -> expr MUL expr
expr -> LEFT_PARENTHESIS expr RIGHT_PARENTHESIS
expr -> NUMBER

Of course we have to define the operator precedence to make it fully correct, but the basic idea is simple. We write a set of rules (called 'productions') saying, how to produce the more and more complex parts of the expressions from the smallest units. For a number of grammar classes, there are computer algorithms that are able to produce a complete parser code for them, and the most popular one for programming languages is called LALR(1). Now all we have to do is to write the grammar in the format accepted by the parser generator and simply run it to produce a ready-to-use code.

For Open Power Template, I chose PHP Parser Generator, a clone of Lemon parser generator rewritten from C to PHP. The same stuff is used by the guys that develop Smarty 3, but they have applied it to parse the whole template. In case of OPT it is not necessary, as it uses an ordinary XML parser. Below, you can see a part of the grammar file that defines function calls:

calculated(res)		::= function_call(fc).		{	res = fc;	}
calculated(res)		::= method_call(oc).	{	res = oc;	}

function_call(res)	::= functional(fun).		{	res = $this->_expr->_makeFunction(fun);	}

functional(f)	::= IDENTIFIER(s) L_BRACKET argument_list(a) R_BRACKET.	{	f = $this->_expr->_makeFunctional(s, a); }
functional(f)	::= IDENTIFIER(s) L_BRACKET container_def(a) R_BRACKET.	{	f = $this->_expr->_makeFunctional(s, array($this->_expr->_containerValue(a, Opt_Expression_Standard::CONTAINER_WEIGHT)));	}
functional(f)	::= IDENTIFIER(s) L_BRACKET R_BRACKET.	{	f = $this->_expr->_makeFunctional(s, array()); }

As you can see, for each production we can define a PHP code snippet that may perform some action, if the specified sequence of symbols is found. This eases the process of defining a language very much.

New features of the OPT expression language

The new parser allowed me to implement lots of new and useful stuff. The most lacking feature in OPT 2.0 was the inability to create a container in a template, like arrays in PHP. We could not write:

{url(container('controller' => 'foo', 'action' => 'bar'))}

The routing path must have been defined either in a script or saved as a string. In OPT 2.1 this limitation is finally removed. We can create new containers dynamically, using a convenient syntax designed for using within XML documents:

xml
{url( [ 'controller': 'foo', 'action': 'bar'] )}
{url('controller': 'foo', 'action': 'bar')}

The shortened version (syntactic sugar) for functions is also possible, as we can see. The two lines above do exactly the same thing. The container call syntax was also extended. Now it is possible to select the container index dynamically:

$container.($index).foo

However, you should be aware that some data formats may not support it and it will not always work.

A lot of effort has been made to develop new operators which you should find very comfortable and convenient, especially with the longer expressions:

$number is between 5 and 10
$number is not between 5 and 10
$number is either 5 or 10
$number is neither 5 nor 10

$container contains 'foo'
$container contains either 'foo' or 'bar'
$container contains neither 'foo' nor 'bar'
$container contains both 'foo' and 'bar'

'foo' is in $container
'foo' is not in $container
'foo' is either in $foo or $bar
'foo' is neither in $foo nor $bar
'foo' is both in $foo and $bar

The first group of operators is a shortened form for expressions like $number > 5 and $number < 10. The second grup tests the contents of containers, allowing to check if they contain one or more specified values. In the last group, the situation is reversed: we check if the element exists in one or more containers. The advantage of the new operators is that they will be able to be reprogrammed with data formats, hiding even more implementation details from the template designer and improving the template portability.

There is only one feature removed. In OPT 2.0 it is possible to write eq eq eq and the parser correctly recognizes, which "eq" is an operator and which is a string. Unfortunately, such trick is not possible with ordinary LALR(1) grammars so I was forced not to implement it in order not to produce a mess.

The last change concerning the expressions is that the direct access to PHP arrays and objects is disabled by default: $foo'bar', $foo::field. Using them instead of containers and data formats is considered as a bad programming practice in OPT, and reduces the template portability. The idea is to encourage the programmers to learn what containers are and why they are better in templates than PHP objects and arrays.

Conclusion

There is still a lot of work to do in Open Power Template 2.1. I hope that after the exams at university I will find more time to finish it. Anyway, I'll do my best to make OPT 2.1 the best template engine ever.

New OPT tutorial

Zyx — Tue, 22 Dec 2009 13:28:00 +0100

I have published a new tutorial for Open Power Template today. It shows how to use sections and data formats for OPT. I chose this topic, because I noticed that some users have problems with understanding them and decided that an extra tutorial would help them. Before the end of the year, I'll try to write one more text about working with XML in OPT. The article is available on Invenzzia website both in English and Polish language versions.

Open Power Template 2.1 - a closer look

Zyx — Sat, 28 Nov 2009 11:35:00 +0100

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.

Reasons for the changes

From the technical point of view, OPT is a pioneer project. Many features were never implemented in any existing template engine and at the first time it was sometimes hard to say what potential they actually offer. We were learning the library during the development process. Unfortunately, the improvements could not be invented and applied forever. One day we had to stop and say: `OK, now it is the time to make it stable'. The result is quite satisfactory, but the list of the things that could be done better was getting longer and longer. Some of the features were suggested by the users, the rest comes from us. OPT 2.1 is going to be the next step in the template engine evolution.

Compiler changes

In OPT 2.1, the compiler becomes a universal framework for implementing template languages, primarily based on XML. It provides the compilation process structure, interfaces and ports for many features, such as data formats. However, the details of the syntax processing are moved to external parts:

Custom parsers - their task is to parse the template source code and construct an Abstract Syntax Tree (AST).
Custom AST nodes - currently, the AST nodes match the specific OPT-XML needs and it is impossible to write new ones without changing the compiler code. In OPT 2.1 it becomes possible.
Custom expression parsers - they parse expressions such as $a+$b. Since OPT 2.1 it will be possible to write new ones.

In other words, OPT is going to bring the compilation structure, whereas the programmer matches it to his or her needs. Personally, I hope that someone will use it and port Template Attribute Language to OPT. However, most programmers will not be interested in the details of compilation process, but rather the default language it offers. Here, OPT 2.1 language will be very similar to the current language. It will be just ported to the new API.

New parsers

By default, OPT 2.1 will offer three parsers that could be used by the programmers. They will replace the current `compiler modes':

XML - completely new parser based on the XMLReader extension. Its primary feature is 100% sure full compatibility with XML standards, including such details, as xmlns attribute. However, the parser cannot be scaled to ignore some syntax requirements.
HTML - the current parser, customizable with many options.
Quirks - the quirks mode parser.

New dynamic attribute value syntax

As OPT is based on XML, there occurs a problem, how to put an expression value into an attribute. In the early development stage, we decided to make use of namespaces to indicate the attributes which have dynamic values. The life shown that it was not the best idea. It is not scalable and causes problems, if the attribute already contains a namespace. Redesigning this feature from scratch was one of our priorities. In OPT 2.1, the value type will be encoded in the attribute value, not in the name. It is illustrated by the following examples:

<p class="text">Static attribute value: text</p>
<p class="parse:$text">Dynamic attribute value read from a variable</p>
<p class="null:parse:tekst">Static attribute value: parse:text</p>

It can be also used to select the custom expression syntax:

<p class="foo:##mysteriousSyntax">text</p>

And in curly brackets, too:

<p>Mysterious syntax: {foo:##mysteriousSyntax}</p>
<p>A bit nonsense example ("parse" is the default): {parse:$variable}</p>
<p>Even more nonsense example, but still possible: {str:$variable}</p>

And in instruction attributes:

<opt:include file="parse:$file" />
<opt:attribute name="str:theName" value="str:value" />

Extended expression modifiers

In OPT 2.0, there were two hardcoded modifiers used for the HTML escaping control: e: and u: used as follows: {e:$expression}. Since OPT 2.1, it will be possible to create custom modifiers and use them in the attributes. Furthermore, there will be three predefined modifiers that could be overwritten:

To enable the escaping (by default e:)
To disable the escaping (by default u:)
To enable the escaping in attributes (by default a: - the new default modifier)

The reason to introduce the new default modifier were the needs of HTML escaping and XSS protection for attribute values that must be a bit more complex than for normal tag body. You will be allowed to use the more complex escaping function for attributes, and the simpler, but faster - for ordinary texts.

Some of you may have noticed that the modifiers use the same syntax, as the expression type chooser. Nothing more further from the truth! Thanks to some simple conventions everything is unambiguous. First of all, to specify both the expression type and the modifier, we specify the parser, and later the modifier: {parse:e:$variable}. Secondly, the modifier name is always one character long. At at last, in the code like this: {e:$variable}, the compiler matches the modifier first and then the expression parser.

Extended data format support

Data formats are probably the most brilliant feature of OPT and in the next branch this element will be greatly improved. Let's take a look at instructions first:

<opt:section name="foo">
 ...
</opt:section>

To specify the data format for thi section, we have to link it with a variable (in this case: $foo), but it is not always possible. For example, the variable may be specified by the datasource attribute or the section could have nothing to do with variables. Such situation occured while developing Open Power Forms. Some sections must be connected to the form and have no equivalent in template variables. And what if we would like to write a new implementation of opt:include? In OPT 2.0 it is impossible to pass the information about the data format to it.

The problem will be solved by introducing a special, optional attribute called id. Obviously, it will allow to define an unique identifier for the instruction which can be used to find the data format definition or modify any other aspect of the behaviour. It leads to the extension of the list of the available data formats. Some of the new ones are:

Include - the default data format for opt:include
System - the $system special variable handling, moved from the compiler code to the data format.
Scalar - the scalar data (text, numbers, logical values) that does not allow the container, array and object access. It will be impossible to use them as section data sources which will improve the template code security and error resistance.
RuntimeIterator - if you do not want to write a custom data format and Objective does not meet your requirements, but you still want to use sections with your own objects and their own logic, this format will allow this. It will work with a special interface that needs to be implemented in your class that provides the whole section functionality.

Snippet arguments

Snippets resemble macros from such languages, as C. A new interesting addition in OPT 2.1 will be the possibility of giving a snippet the arguments. I have not invented a syntax for this element yet, so please treat the following code as the illustration of an idea:

<opt:snippet name="snippet">
 <p>{$info.foo}</p>
 <p>{$info.bar}</p>
</opt:snippet>
 
<opt:section name="foo">
<div>
 <p>Some content</p>
 <opt:insert snippet="snippet" info="$foo" />
</div>

Now the snippet variable $info will be treated as $foo, keeping its data format and features. It will make the snippets much more portable.

Snippet loading

Currently, the shared snippets can be included in our template in two ways:

Template inheritance
opt:root attribute include

The last way will be extended by a special tag opt:load which will allow to load multiple templates with snippets:

<opt:root>
  <opt:load template="snippets_1.tpl" />
  <opt:load template="snippets_2.tpl" />

  <!-- the code here -->
</opt:root>

Template functions

Snippets have one important disadvantage: they are static and exist only during the compilation. It is impossible to select the snippet name from a variable or something like that. Many people ask for such a feature, and the problem became known as "dynamic snippets". I did a long research looking for the possible ways of adding this feature, but due to the PHP language construction and the snippet features, it seems to be impossible. The snippets cannot be implemented as functions or class methods, because:

The access to the template variables {@variable} will be lost.
The access to some internal compilation code variables will be lost, which could lead to serious problems with data formats.
The snippets would be strictly connected with one, particular data format, whereas they should match the current data format in the place of insertion.

This is why I decided to introduce a new language element which does not have an official name yet, and during the development process we call it "template functions". Why? Because it is a reimplementation of the classic PHP function features. They are created once and physically called, intead of being copy-pasted during the compilation, like in snippets. What is more, they will support a dynamic selection of the called function.

My plan is to implement them so that they could be used in many places, where the snippets can be currently applied:

Section bodies
Components
Blocks

Of course some of the locations will be unavailable for them and moreover, they will be strictly connected to a single data format. An interesting feature is that they could be injected into the component objects, like (please remember that the syntax is not invented yet):

<!-- define a layout of the checkbox list for the checkbox component -->
<opt:function name="checkboxListLayout" list="required">
  <ul>
  <opt:section name="list" datasource="$list">
    <li>{u:$list.checkboxCode}</li>
  </opt:section>
  </ul>
</opt:function>

<form:checkbox-list name="list">
  <label for="parse:$system.component.id">Select something:</label>

  <!-- dynamically select the layout to inject -->
  <opt:display inject="$system.component.layout" />
</form>

Improved section syntax

Together with the current syntax with opt:show and the empty section tag, in OPT 2.1 it will be possible to use the new style presented by the example below:

<opt:section name="foo">
	<opt:body>
		<ol>
			<opt:item>
			<li>Dodood</li>
			</opt:item>
		</ol>
	</opt:body>
	<opt:else>
		<p>Hi universe!</p>
	</opt:else>
</opt:section>

As we can see, in place of opt:show we write the section tag, and in the body we use opt:body to indicate the section body and opt:item to specify a place which will be iterated. The current syntax will not be removed, as they are complementary to each other, mostly when it comes to the cooperation with snippets. I was also asked for the possibility of having the section body enclosed in an extra tag which is quite useful if we have an extra opt:else at the same place, and want the body to be loaded from a snippet.

Moreover, the small changes will be applied to the opt:selector instruction:

<opt:selector name="foo">
	<opt:select item="fff">ssdf</opt:select>
	<opt:select item="ssddf">ssdf</opt:select>
	<opt:select item="abc">ssdf</opt:select>
</opt:selector>

In other words, it will be no longer necessary to create thousands of new tags for our choices.

Switch instruction

OPT 2.1 will introduce the new instruction: opt:switch. Contrary to the switch statements from the classic programming languages, it will be a real swiss knife. Take a look:

<!-- classic switch -->
<opt:switch test="$condition">
 <opt:equals value="value1">Body...</opt:equals>
 <opt:equals value="value2">Body...</opt:equals>
 <opt:equals value="value3">Body...</opt:equals>
 
 <!-- an equivalent of playing with "break" -->
 <opt:equals value="value4">
   Some content...
   <opt:equals value="value5">
     Some content...
   </opt:equals>
 </opt:equals>
 <opt:default>...</opt:default>
</opt:switch>

If you like the power of case... break construct in PHP, you will surely enjoy this stuff:

 <opt:equals value="value4">
   Some content...
   <opt:equals value="value5">
     Some content...
   </opt:equals>
   Some content...
   <opt:equals value="value6">
     More optional content
   </opt:equals>
   The ending
 </opt:equals>

If the tested condition equals value5, we will see just the contents of the value5 tag. But if it equals value4, we will see its contents, together with value5 and value6. But this is not the end. OPT switch will work with... containers:

<opt:switch test="$container">
  <opt:contains value="foo">body...</opt:contans>
  <opt:contains value="bar">body...</opt:contans>
  <opt:contains value="joe">body...</opt:contans>
</opt:switch>

In this case, OPT will be able to display the values of more than one choice. opt:contains could also be nested, similarly to opt:equals. And what would you say, if you see that they can be mixed?

<opt:switch test="$condition">
  <opt:contains value="foo">body...</opt:contans>
  <opt:contains value="bar">body...</opt:contans>
  <opt:contains value="joe">body...</opt:contans>
  <opt:equals value="value1">Body...</opt:equals>
  <opt:equals value="value2">Body...</opt:equals>
</opt:switch>

In this case, OPT simply checks the expression type. If it is a container, it matches the opt:contains tags, otherwise - opt:equals. Nested cross-mixing of opt:equals and opt:contains is also possible.

We get even better functionality, if we use the attribute form of opt:switch:

<ul opt:switch="$row">
 <li>Name {$row.name}</li>
 <li>Age: {$row.age}</li>
 <li opt:contains="city">City: {$row.city}</li>
 <li opt:contains="email">E-mail: {$row.email}</li>
 <li>Date: {$row.date}</li>
 <li opt:contains="other">Other: {$row.other}</li>
</ul>

And the finale that will help in the last example. Suppose that we would like to add the class="last" attribute to the last displayed list element. This could be done by the following code:

<ul opt:switch="$row">
 <li>Name {$row.name}</li>
 <li>Age: {$row.age}</li>
 <li opt:contains="city">City: {$row.city}</li>
 <li opt:contains="email">E-mail: {$row.email}</li>
 <li>Date: {$row.date}</li>
 <li opt:contains="other">Other: {$row.other}</li>
 <opt:append to="last">
   <opt:attribute name="str:class" value="str:last" />
 </opt:append>
</ul>

For everyone who claim that "PHP is the best template language": enjoy implementing similar functionality manually.

Futher changes in syntax

During the development process, there have occured some inconsistences in the naming style of the instructions. OPT 2.1 will attempt to fix them. Basically, all the tags named opt:someTag will be renamed to the form opt:some-tag. In sections, monsters like opt:sectionelse will be shortened to opt:else. opt:use will be renamed to opt:insert, and opt:on into opt:omit-tag.

Inflectors

This feature concerns the public library API and is related to finding the templates in the filesystem. I was talking to some programmers and the developers of CMS-es etc. They were often complaining about the current, hard-coded algorithm of mapping the template names to the files based on the streams. They said that it is very impractical, when it comes to the modular applications - it is very hard to manage the registration of dozens of quasi-streams, and operating them on the script- and template side. They would enjoy a system that would give them more flexibility. This is how the idea of inflectors was born. An inflector is a simple class that gets the "public template name", such as `db:user/edit.tpl` and returns the real filesystem path to it. The default OPT inflector is basically the reimplementation of the current template locating algorithm. It is just extended by an extra API for managing the streams. However, if the programmer needs some specific rules, he can write a custom inflector and deal with it on his own.

Backward compatibility

OPT 2.1 is intended to be used in new projects, however - if you stared writing something with OPT 2.0, you do not have to worry. Although the syntax changes can bother many programmers, there is no need to worry. OPT 2.1 will have a backward compatibility mode. Basically it activates the whole old and replaced syntax, with keeping the new features at the same time. You can use this mode to make use of the new features and give yourself some time to make a migration. What is more, many changes are just syntactic, not semantic. I plan to write a special tool that would convert the existing templates to the new syntax with one click.

Note that if you actually want to be up-to-date, the migration at some level will be necessary. The OPT 2.2 branch will be basically OPT 2.1 with the backward compatibility code removed.

Support

If you want to stay with OPT 2.0 in your current projects, the support for this branch will be continued long after the OPT 2.1 will be released. We will fix the encountered bugs and continue improving the stability of this branch. Actually, OPT 2.1 is going to be a transition branch to the next evolution level. The plans are as follows:

OPT 2.0 - works on PHP 5.2, the support is continued for at least one year after releasing OPT 2.1
OPT 2.1 - the new branch with new features and the full backward compatibility mode. The minimum requirement is PHP 5.3
OPT 2.2 - backward compatible with OPT 2.1, but without the 2.0 compatibility mode. Also, the very long support is planned.
OPT 3.0 - basically the same as OPT 2.2, but with the entire code migrated to PHP 6 and namespaces.

Note that OPT 2.0, 2.1 and 2.2 are also supposed to work on PHP 6 as soon as it will become more stable, because nowadays I even have serious problem with compiling the development snapshots.

Changes to the OPL core

As you can see, the new branches will require the improvements of the OPL core. The planned features are:

OPL 2.1 - new features: namespace support, command line interface tools, new debug console implementaton, improved error handling.
OPL 2.2 - removing legacy code for compatibility with OPL 2.0
OPL 3.0 - migration to PHP 6 and namespaces

Conclusion

OPL project is getting more and more mature. The new features will make it more suitable to deal with new problems and situations, where the template engine support is needed. At the same time, I think about how to introduce the new users in the project and teach them, how to use the offered tools. You can expect new tutorials, and personally, I think it would be nice to write a book after releasing OPF and OPT 2.2...

Invenzzia on SlideShare

Zyx — Sat, 26 Sep 2009 11:01:00 +0200

I have just created an account on SlideShare.net, a place where you can post your presentations and slideshows. I will use it to post various presentations and learning materials about Invenzzia projects, so that you could follow them easily. Currently, you can watch there a tour on Open Power Template (watch on SlideShare). So stay tune and follow us on SlideShare!

A closer look at Open Power Forms

Zyx — Sun, 06 Sep 2009 09:20:00 +0200

After releasing the first stable version of Open Power Template, we gained an opportunity to focus on other Invenzzia projects as well. One of the new enterprises is a form processing library which has been given a name Open Power Forms. In the last days, I managed to implement the basic functionality and run the first test files and I would like to introduce you in the new project. From this entry, you are going to get to know, what OPF actually is, what are its benefits and main goals and what has been implemented so far.

Open Power Forms

Open Power Forms is a form processing library. It manages the logic behind the forms and allows the programmer to create them with a set of simpler rules. He simply defines what he would like to see there and waits for the input data. The complete task list of a form processor can be found below:

Providing a system to define the content of a form and its behaviour: validation rules, data filters, information messages etc.
Rendering the form in the HTML format.
Validating the input data and filtering them in order to prepare them to be processed by the application logic layer.
Validation error handling and informing the user about the problems.
Managing the form layout.

As you can see, form processors play an important role in a web application. Most of the communications between the user and the script passes through forms and having a good management system for this element should be necessary. We get the unified set of rules and behaviours which speeds up the development process and eases the mainternance.

The goal

The web frameworks usually introduce their own form processing system, but sometimes is too simplified to satisfy the requirements. An example of such framework is Kohana, where we have validators, view helpers and nothing more - it is our task to build and implement the whole logic, using these elementary blocks. The other ones provide a convenient API, but lack of the more advanced features, such as multi-page forms or offer a limited choice of widgets, validators and filters. In this group the best example is Zend_Form, a part of Zend Framework. The last important problem concerns the rendering system. It is very easy to display a form, but hard to customize it. Zend_Form forces us to use massive OOP and design patterns in order to customize the HTML code which can easily break the MVC pattern by moving the view tasks to the logic or controller layer. At the same time, sfForm from Symfony provides a concept of template templates, small files written in PHP that are compiled by the extra compiler to build the form layout. Anyway, if we want to customize the look, we have to be prepared to lots of coding in PHP. The main disadvantage is that the developers of freamework-based solutions usually have no time to provide a more generalized solution which leads to wheel reinvention and the problems with code refactoring.

And we want to create a general-purpose form processing library free of those disadvantages.

OPF features

The key features of Open Power Forms are the form management logical model and the rendering algorithm. We begin with focusing on the first issue. Most of the form processors treat the form as a list of atomic fields, sometimes grouped. It is very easy to implement such a form processor, but it cannot handle more advanced forms. Let's imagine the column insertion form in phpMyAdmin. It allows the administrator to add several columns at the same time by multiplying the same form several times in the table rows. Other web applications may use multi-step forms, where the user fills the form called "Step 1", then goes to "Step 2" and so on. The entire data are processed after filling in the final step. What is more, some steps may be activated only if the user made a certain choice in the previous ones. The better model to represent such situations is to unify the concepts of a form and a form field. Open Power Forms formally makes no difference between them. We are allowed to append one form as a field of the other form, guaranteed the library will recognize our intentions.

If we are talking about not-reinventing-the-wheel in the form rendering issue, we must throw away all the ideas that do not work in the other libraries. They rely on PHP and they fail, but we already have a great template language provided by Open Power Template. It offers us some brilliant features, very useful in the form rendering, that is components and snippets. The component system has been designed especially for forms - we work there with components, which are various form widgets, such as input fields, select lists, radio buttons etc. Components separate the field logic (managing the labels, IDs, attributes, errors etc.) from their presentation. The field logic is implemented in a PHP class, and the presentation with a component port in a template. A sample port looks like this:

<opt:inputComponent name="foo">
  <div>
    <label parse:for="$system.component.id">{$system.component.label}</label>
    <opt:display />
    <opt:onEvent name="error">
       <p class="error">{$system.component.error}</p>
    </opt:onEvent>
  </div>
</opt:inputComponent>

In the example above, we create a statically deployed port, where the template automatically creates a component object for it, using the tag name (opt:inputComponent). But we have also standalone ports, where we load the component from a template variable, and the component itself may be created with a script. In both cases, the content of the XML tag remains the same. What is more, we can use snippets to save the form layout in one place and simply insert it in all the ports of all the forms we have:

<opt:snippet name="fieldLayout">
  <div>
    <label parse:for="$system.component.id">{$system.component.label}</label>
    <opt:display />
    <opt:onEvent name="error">
       <p class="error">{$system.component.error}</p>
    </opt:onEvent>
  </div>
</opt:snippet>

<opt:component from="$variable" template="fieldLayout">
  <!-- we can set some attributes here -->
</opt:component>

At any time, we may decide, whether to implement a field-specific layout for particular components or use the default ones. Moreover, we operate on simple HTML with some extra tags without the need to create hundreds of files and deal with the implementation details, as OPT hides the unncecessary logic from us.

Open Power Forms is going to provide a set of OPT-compatible components integrated with the form processing system, plus some extra tags, data formats and functions for designing forms and managing their layouts. Below, we can see a working template that uses the new features:

<?xml version="1.0" ?>
<opt:extend file="base.tpl">
  <opt:snippet name="title">Situation 1</opt:snippet>
  
  <opt:snippet name="content">
	<!-- configure CSS styles for the elements -->
	{$design.form.valid is 'form'}
	{$design.field.valid is 'row'}
	{$design.field.invalid is 'row row-error'}
	{$design.input is 'inputText'}
	
	<!-- display a form -->
	<opf:form name="form1">
		<div class="errors" opt:if="not $system.form.valid"><p>The form is invalid.</p></div>
	 
	 	<!-- load the components assigned to the "default" placeholders -->
		<opt:section name="default">
 			<opt:component from="$default.component" template="widget">
			</opt:component>
		</opt:section
		
		<!-- some final stuff -->
		<input type="submit" value="Submit" />
	</opf:form>
  </opt:snippet>
</opt:extend>

And here is the PHP part of the form:

class My_Form extends Opf_Form
{
	// An event
	public function onInit()
	{
		$item = $this->itemFactory('title');
		$item->setRequired(true);
		$item->addValidator(new Opf_Validator_Length(5), 'The length is invalid');
		$item->setWidget(new Opf_Widget_Input)
			->setLabel('Title');

		$item = $this->itemFactory('countries');
		$item->setRequired(true);
		$item->addValidator(new Opf_Validator_Type(Opf_Validator_Type::INTEGER), 'The field type is invalid.');
		$item->setWidget(new Opf_Widget_Select)
			->setLabel('Countries');
	} // end onInit();

	// An event
	public function onRender()
	{
		$view = $this->getView();
		
		$item = $this->itemFactory('countries');
		$item->getWidget()->setOptions(array(0 =>
			'China',
			'France',
			'Germany',
			'Great Britain',
			'Poland',
			'Russia',
			'Spain',
			'United States'
		));
	} // end onRender();

	// An event
	public function onAccept()
	{
		$view = $this->getView();
		$view->setTemplate('results.tpl');
		$results = array();
		foreach($this->getValue() as $name => $value)
		{
			$results[] = array('name' => $name, 'value' => $value);
		}
		$view->results = $results;
	} // end onAccept();
} // end MyForm;

The list of core features:

Flexible design - the forms can be constructed either by extending the base form class or by configuring the bare form object and responding on the events.
Event listeners - they can be used to implement the logic of common form parts by extending the initialization or rendering events. The concept is similar to event listeners and behaviours in Doctrine ORM.
AJAX support - the AJAX requests could be implemented as ordinary form events and the library will set up the entire communication process.
Huge (and useful) set of widgets, validators and filters.
Web Forms 2.0 support.
CSRF attack protection.
Support for complex forms: multi-step forms or forms built of smaller forms.
Doctrine ORM support out-of-the-box.
Full integration with Open Power Template library.
Internationalization support.
Integration with Zend Framework thanks to the already available OPL port for Zend Framework.

Current status

The library currently implements the most important core features, such as data validation, error reporting and form rendering and is able to process simple forms. We are currently working on extending the logical model in order to support more complex forms and their proper rendering. In the very near future, the first development version will be released. We would appreciate any suggestions and ideas.

Conclusion

The goal of Open Power Libs project is to develop innovative PHP libraries. The success of Open Power Template has shown us that there exists a demand for solutions that break the stereotypes and give the programmers a fresh point of view of the well-known issues. Open Power Forms is a next step towards satisfying them and developing a complete presentation layer for web applications.

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.

Invenzzia Summary #4

Zyx — Wed, 20 May 2009 15:04:00 +0200

Welcome to the fourth episode of Invenzzia Summaries. The issues discussed today:

Incoming TypeFriendly 0.1.2 release
Revised plans for 0.2 branch of TypeFriendly
Open Power Classes
Release plan for Open Power Template

Incoming TypeFriendly 0.1.2 release

Before the end of May 2009, Invenzzia is going to release TypeFriendly 0.1.2, a HTML documentation builder with Markdown syntax. It will contain some new features and improvements that can be currently found in the SVN repository:

New tag manager that validates the contents and use of the tags in the chapters.
Support for creating appendices added.
New tags:
- MultiExtends - specifying the base classes for languages with multiple inheritance
- Throws - thrown exceptions.
- Construct - specifying the type of described programming construct (classes, interfaces etc.)
- Type - specifying the item type
- Arguments - specifying and describing the function arguments
- Returns - describing, what the function returns.
- VCSKeywords - a place for expanding SVN keywords that can be also optionally displayed in the output.
- Appendix - support for appendices
- FeatureInformation - allows to define a messages in the project configuration that may be later prepended to the chapters.
Improved command-line interface. The usage has been changed (please take a look at the details on wiki)
New book creation wizard.

The release will also fix some bugs found in the previous release.

Plans for TypeFriendly 0.2

The release of TypeFriendly 0.2.0 has been moved further to the future (Summer 2009) due to the recent revision of the goals. The new TypeFriendly will consist of three parts:

TypeFriendly library - the documentation management functionality will be collected into a library independent from the command-line interface code that can be used by the programmers to include the TypeFriendly documenting system features into their project.
Command-line interface - build with TypeFriendly library will provide the features similar to the current TypeFriendly 0.1 release.
Web interface - since 0.2.0, you will be able to install TypeFriendly web interface on your website to run a public documentation repository with automatic uploaders, user comments etc. This feature is addressed especially to the developer teams that wish to publish the on-line documentations for their products.

TypeFriendly 0.2 will use Open Power Template both to render the static documents and in the web interface. The Markdown parser will be expanded with new features, such as mathematical formulas support. However, generating the documents in other formats than HTML will not be still possible, as we need to design our own Markdown parser and this is a longer-term goal.

Open Power Classes

The development of Open Power Classes slowly begins. eXtreme added a nice paginator class with OPT support, and I am working on the native caching system for OPT that will be available as Opc_Cache. Open Power Classes is going to be a collection of small utility classes to support other libraries.

Release plan for Open Power Template

There will be another Release Candidate version, as there have been found some small, but annoying bugs in the parser. The first stable version will be released in the first half of June then.

They wrote about...

Last Saturday, a nice note about TypeFriendly was published by Federico Cargnelutti on his blog. We are looking forward to the next publications about Invenzzia projects.

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 #3

Zyx — Tue, 12 May 2009 10:38:00 +0200

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.

100th revision to the OPL repository

The Subversion repository has been used in OPL development for ages. However, for the first six months, Open Power Template 2 had to deal without any version control system due to the movement to the new group and abandoning the old network infrastructure. The first revision to the new repository was committed on 30th June 2008 and was relatively poor - in other words, nothing worked. In the last few months the use of the repository has significantly increased, providing the users the freshest versions of the source code and the documentation. Only in the last two weeks, there were 14 new revisions.

The 100th commit has been made to the OPL library. It includes the newest improvements to the autoloader and the PHAR builder.

New OPL autoloader

Recently, I have been corresponding with Amadeusz Starzykiewcz about the OPL autoloader improvements. We decided that it would be the best to make it more a general-purpose autoloading tool that suits not only OPL needs, but other libraries (i.e. Doctrine and Zend Framework) as well. The result is visible as the improved API with many limitations removed. The most significant changes are:

The autoloader can handle any library using the Foo_Bar_Joe class naming style.
The library-specific autoloading needs have been moved to the extra handler. Different libraries may use different handler or not use any.
Improved library configuration with addLibrary() method.
Added performance-tuning methods.
The special handler for PHAR-s is present.

PHAR support

The full PHAR support has been one of the primary goals for a long time. However, for most of the time, there were other priorities that must have been done, but finally there appeared the PHAR builder in the repository. It allows to produce a fully-functional PHAR from any OPL library. The archive is self-configurable and contains only the executable code. The PHAR-s will be available to download from our website together with the ordinary distribution packages.

The installation and usage of PHAR-s is described both in the OPT and OPL documentation. Please note that you need PHP 5.3 or PHP 5.2 with installed PHAR extension in order to use it. As we have the PHAR support, we need to work on the performance a bit. The developers claim that PHAR-s can be as fast as the ordinary files, but our tests show that OPT and OPL archives work a bit slower than the classic solution. Fortunately, it is only a matter of time. This is a relatively new piece of technology and we have to do some research in order to determine, how to get more from it.

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.

Invenzzia Summary #1

Zyx — Fri, 10 Apr 2009 22:02:00 +0200

This is the first episode of the Invenzzia Summaries, a way to inform about various events and activities of Invenzzia Group and the development of the open-source projects. We will try to publish them regularly, but the exact period depends on the amount of issues worth concerning. In the first episode, we will talk about the last beta version of Open Power Template and the new projects that are going to use it.

Open Power Template 2,0-beta3

This is a pretty fresh news, because the packages have been published about an hour ago. The new and the last beta release contains lots of various bugfixes and improvements, such as new, more stable section implementation or data formats. Finally, the entity issue has been also solved once and for all. We have decided to use the XSLT model, where the entities are parsed on the server-side, and only the special XML characters appear as entities in the output. The end user will see no difference, especially if he/she uses Unicode. For those ones who need to display a particular entity in the output, there is a new function: entity(). Please note that it must be used with the escaping turned off, for example:

<p>The entity: {u:entity('Acute')}</p>

The new version can be downloaded from here.

The remaining issues in OPT.

One could ask, what needs to be checked in OPT before the first stable release will appear. Well, the library is already pretty stable now, after some recent bugfix parties and significant effort taken by the users in finding them. The only feature that has not been tested yet is the cache interface port. Furthermore, there are some unit tests still to write and the documentation to finish. Currently, the test suite consists of about 400 unit tests, but there are some areas that are poorly covered with them:

Template functions.
The standard data formats.
XML node manipulation API.

Now, just to finish the remaining jobs and release the first stable version.

Who uses OPT?

Recently, the development team of Extreme-Fusion CMS announced that Open Power Template 2 will be the primary template engine in the new version of their project, EF V. Extreme-Fusion is a quite popular Polish CMS, a fork of PHP-Fusion. The new version is going to be rewritten from scratch on the Kohana framework and OPT 2. Those who know Polish, may read the announcement on their development blog (unfortunately, they do not provide English-language version, like Invenzzia :( ).

Another application that uses OPTv2 is the project with the codename "Arbiter". It is a system for AGH University of Science and Technology in Krakow that allows to organize programming competitions and automated program testing for computer science students. Because I'm involved in its creation, I'll try to write more about it in the next few days, as the first version is going to be run soon. The application is built on Zend Framework, Doctrine and OPTv2. It has been used as the prototype for the OPL4ZF port and the experimental field for OPTv2.

What about Open Power Classes?

The "Opc" directory remains empty on SVN, however this should change in the near future. The problems were caused with the huge amount of work with OPT debugging and I couldn't find more time to push this project, too. Moreover, I'm preparing the UML design for Open Power Forms, a form management tool based on OPT. I'll try to publish the results in the next two weeks.

Polish support improvements?

A few days ago, two users contacted Invenzzia asking for the possibility of establishing a better Polish-language support. The support concerns translating the original English materials into Polish on a secondary wiki. Currently, we are thinking, how to set up a bilingual infrastructure. We are pleased that the Invenzzia community grows constantly and becomes more and more active, however it would be nice to see more non-Polish users here. As you can easily notice, the main language is English and receiving support in this language is as easy, as in Polish. The Czech and Slovak users may also attempt to contact in their native languages, as one of the team members knows Slovak and may understand them :).

Conclusion

This is the end of the first Invenzzia Summary. I hope you have enjoyed this form of providing the recent news and issues.

New Invenzzia website is on-line

Zyx — Wed, 01 Apr 2009 22:03:00 +0200

A couple of minutes ago, we have finally run the new Invenzzia website with new layout, navigation and features, such as news/article commenting. We hope you'll enjoy it and we are waiting for your feedback and opinions. Please note that the links to the user manuals have been changed, as well as the download links. However, we keep the automated redirects.

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.

What's new on Invenzzia?

Zyx — Sun, 22 Mar 2009 10:12:00 +0100

Hi everyone, in the last few days, we had a lot of work around Invenzzia and its projects. In this entry I would like to inform, what currently is going on. We will talk about OPT 2, TypeFriendly, our new website and the activity in open source project trackers.

Open Power Template 2

A few minutes ago, I have commited a quite big revision, an effect of four coding days. In this time I solved a number of problems:

I decided to reimplement the whole section handling code from scratch, because the old one had a significant problem with handling custom section attributes that I was unable to fix with the old design. The new code is much cleaner, simpler and seems to be more stable. To check it, I wrote more that 20 new unit tests to check various edge conditions and integration with other instructions. From the end-user side, you should see no difference and the old code should be still 100% functionable.
At the same time, I finally cleaned and "standarized" the data format structure. The definitions of the five default data formats have been improved, too. There is a small change that could break the backward compatibility - the "Generic" format has been renamed to "Array" to reflect its real nature. Unless you declared the use of this format explicitly, your code should still work.
Another, quite big part of PHP code was equipped with phpdoc and more comments. If you are using a good IDE, like NetBeans or Eclipse PDT, they should show you the complex information about much wider variety of OPT methods.
A number of bugs was fixed.

Significant improvements have been applied to the user manual, too. The API reference was moved to the bottom and the more practical chapters were exposed. I decided to create a new section, "Programmer's guide" that aims to be a complete guide over OPT API issues and its practical usage. It incorporated the old "API issues" chapter. The currently written parts show us, how to start and explain:

The initialization process.
Using views.
Using output systems.
Exception and error handling
Data formats
Internationalization
HTML escaping.

The user manual can be read here.

TypeFriendly 0.1.1

A week ago, Invenzzia has released TypeFriendly 0.1.1 with a number of bugfixes found since the first release. Currently, we are focusing on TypeFriendly 0.2 and we will try to release it much sooner :).

New Invenzzia Website

Finally, we are almost ready to launch our brand new website and replace the current temporary one. Yesterday, eXtreme ran it experimentally on our server and now tests it and implements the last remaining features. The website is equipped with a new design and logo (you can already see it on our wiki). It improves the navigation a lot and shows much more useful stuff to the visitors. I hope we will see it online in the next few days.

OPT on Ohloh.net

A few days ago, I created the profile of "Open Power Template 2" on Ohloh.net website. Currently, you can find there some links, a journal of the recent works and the code statistics. We encourage everyone that have an accoun on Ohloh and use OPT to track this project and vote for it :).

Zend Framework port for OPL

Zyx — Tue, 10 Mar 2009 09:04:00 +0100

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.

The ZF port for OPL will be released somewhere in the next week - it is developed as a standalone part of a real-world application and works as a replacement for the certain view elements in ZF and the extension of the rest in other cases. The details have already been published on our wiki: OPT Port for Zend Framework and if you are interested, feel free to read it.

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.

Wiki.invenzzia.org

Zyx — Sun, 08 Feb 2009 17:06:00 +0100

Our new wiki is available on-line now. I've been working for last few days to customize it and add the necessary extra functionality. However, there is still a lot to do. As you can notice, there must be added many technical templates, help pages and some navigation structure. I hope I'll manage to deal with it in the nearest days. The wiki is intended to keep community-driven materials on our open-source projects, as well as extra information on add-ons, such as framework ports. Feel free to share your solutions with everyone - you need only the discussion board account and some knowledge on MediaWiki syntax.

Big Invenzzia website update

Zyx — Sun, 18 Jan 2009 15:04:00 +0100

Today morning I've found on webresourcedepot.com a post written four days ago entitled "19 promising template engines". On the fifth position, I noticed the familiar logo of Open Power Template and a description that perfectly matched the 2.0.0-beta version. The link was redirecting to the Invenzzia website. I followed it and I was shocked - I forgot to update the main Invenzzia website! Invenzzia is no longer bilingual for some time, and here still lots of pages were empty, whereas the Polish text was very out-of-date. This was how we welcomed English readers for a couple of months :(. I decided not to wait till ~~Extreme~~ eXtreme (argh, note the uppercased letter - JJ) will finish the new website and to update all the information as soon as possible. And here it is!

What has been changed:

All the pages have full English text.
The new FAQ has been written.
A set of OPT advices has been published.
The information on the libraries has been changed.
The first OPTv2 tutorial has been published: OPT quickstart.
Another English documentation update.

Next tutorials are on the way. I hope you enjoyed this new stuff and that the website is a bit more useful now.