Invenzzia... in English - Tag - development

Invenzzia reactivation

Zyx — Fri, 14 Jan 2011 13:34:00 +0100

In the last few months, Invenzzia Group websites became a bit outdated, and the projects went into a more chaotic development flow. It was related to some private issues, but finally better days have come and I would like to announce the incoming Invenzzia Group reactivation and refreshment. Read more to see, what is going to change in the next month time.

The most noticeable change will be a complete reorganization of our web infrastructure. eXtreme is making a new CMS and it is mostly completed, and we will abandon or replace some web tools we are using:

Website - a new website with new content organization that will ease the access to project information and materials.
Version control system - last year, we migrated from Subversion to Git thanks to Github service. However, our network infrastructure still does not reflect this change. We are going to finish the migration, and introduce the new, successful and well-tested workflow. We expect it will shorten the development time and allow to improve our software quality.
Bugtracker - we are rather certain that Flyspray will be abandoned. Two alternatives are taken under concern: another bugtracking software or simply using Github for this purpose, as we have already moved the repositories there.
Discussion board - it is going to stay, perhaps with the same software.
Blog - not decided yet.
Wiki - to be removed.
SVN repositories - to be removed.
Documentation repository - will be extended and improved.

The next scheduled change is introduction of the new working schemes, and software quality standards. My vision is to ensure that every project released by Invenzzia Group follows the unified, well-designed rules that guarantee a good and flexible design. We will put even more attention on proper testing and documentation, so that no piece of software will be released without these elements. The development cycle is going to become more regular, and shorter. New major versions are expected to appear approximately every 6 months.

And finally, the projects... what do we keep, what do we abandon? The new base family of projects will include:

Trinity Framework - a web framework for PHP 5.3+ with innovative MVC architecture implementation. Contrary to the existing frameworks which rather follow many of the MVC pattern derivatives, Trinity is based on the original implementation without any modifications except those necessary for the web environment adaptation. It is currently being developed by me as an experimental framework on Github.
Open Power Libs 3 - the new edition of our Open Power Libs foundation, redesigned from scratch.
TypeFriendly Documentation System - the project is going to go through a great redesign in order to make it even better and more attractive for programmers interested in writing their own documentation. eXtreme will become the new project leader.

In addition, two new libraries are expected to appear:

Yii Framework MongoDB Driver
Native PHP Git Library

Stay tuned, as this is not over. It's the beginning.

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.

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.

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...

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.

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.

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.

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.

SVN layout changes in OPL

Zyx — Tue, 23 Dec 2008 17:00:00 +0100

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

The new repository layout will consist of two parts:

components
releases

The components are simply the libraries which will be splitted. Their directory structure will be similar to the current one. For example, OPT will be packed as:

/components
/components/Opt/trunk
/components/Opt/branches
/components/Opt/tags
/components/Opt/trunk/docs
/components/Opt/trunk/lib
/components/Opt/trunk/lib/Class.php
/components/Opt/trunk/examples
/components/Opt/trunk/tests

However, unless you are a developer, you will probably have nothing to do with that directory, as it will be used for development purposes only. The end-user packages are always built of at least two libraries (the correct one and OPL, there might be some extra dependencies). This property can be found in the releases directory. It will be also splitted into trunk, branches and tags. Now, if we want to checkout the 2.0 branch of OPT ready to use, we go into /releases/branches/Opt-2.0/. There will be packed OPT and the necessary OPL core in the layout that you are already familiar with.

The new layout can be viewed online in our sandbox repository. Note that the libraries have not been physically imported there, only the raw directory structure is introduced: svn.invenzzia.org/svn/sandbox.

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.

Open Power Classes: Visit information

Zyx — Sun, 28 Sep 2008 21:55:00 +0200

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

Currently, the class Opc_Visit provides the following information:

IP address
Host address
Current request addresses, paths, file names, all server-independent, mod_rewrite-independent etc.
Accepted browser languages, sorted by the priority.
Cookie server and cookie path detection.
Protocol and port detection.
Browser detection (recognizes 26 browsers and search engines)
Operating system detection (recognizes 10 Windows versions, 14 Linux distributions and 7 other Unix clones, including MacOS).

Below, we can see a sample test script output called on my computer as http://opl.libs.lh/trunk/dev/opc/test_visit.php/foo?bar=joe:

IP: 127.0.0.1
numericIP: 2130706433
host: localhost.localdomain
currentAddress: http://opl.libs.lh/trunk/dev/opc/test_visit.php/foo?bar=joe
currentFile: http://opl.libs.lh/trunk/dev/opc/test_visit.php
currentParams: /foo
currentPath: http://opl.libs.lh/trunk/dev/opc/
fileName: test_visit.php
pathInfo: /foo?bar=joe
protocol: http
port: 80
secure: false
languages: array ( 0 => 'pl-PL', 1 => 'pl', 2 => 'en', )
browser: Opera 9.52
OS: Arch Linux 
cookieServer: opl.libs.lh
cookiePath: /trunk/dev/opc/

The class API is more than simple:

php
<?php
	// OPL Initialization
	require('../../lib/opl/base.php');
	Opl_Loader::setDirectory('../../lib/');
	Opl_Registry::setState('opl_debug_console', true);
	spl_autoload_register(array('Opl_Loader', 'autoload'));
    
	try
	{
		$visit = Opc_Visit::getInstance();
    	
		$paramList = array(0 =>
			'IP', 'numericIP', 'host', 'currentAddress', 'currentFile', 'currentParams', 'currentPath', 'fileName',
			'pathInfo', 'protocol', 'port', 'secure', 'languages', 'browser', 'OS', 'cookieServer', 'cookiePath');
		
		echo '<ol>';
		foreach($paramList as $par)
		{
			$value = $visit->$par;
			if(is_bool($value))
			{
				$value = ($value ? 'true' : 'false');
			}
	 		elseif(is_array($value))
			{
				$value = var_export($value, true);
			}
			echo '<li>'.$par.': <code>'.$value.'</code></li>';
		}
		echo '</ol>';
	}
	catch(Opl_Exception $e)
	{
		Opl_Error_Handler($e);
	}
?>

We have here the singleton implementation and the magic __get method used to generate and return the requested values.

The class will be available in our SVN repository tomorrow or on Thursday, because I must clean up the code and add the recent inventions, such as Google Chrome or Windows Vista to the detectors.

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.

TypeFriendly

Zyx — Wed, 02 Jul 2008 21:38:00 +0200

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

So, TypeFriendly is a documentation writing tool, but it works differently than for example phpDocumentor which scans the source code of your project and makes a reference list of all classes and functions. Here, we write all the chapters and put them in the required order on our own, like in DocBook. However, in this place the similarities end, because TF already contains everything we need. Moreover, it was designed to be intuitive and easy to learn.

Features:

In TF, we write our manual in standard text files using the Markdown syntax. We can put some extra information with tags placed at the beginning of the file. They allow us to define a title, version information or "See also" section.
TF automatically sorts our files and connects them into bigger chapters, basing on their file names. By default, all the content is sorted alphabetically, but we can easily change it for all the files we need. We just create an additional file with "sorting hints", where we write the required order.
There is a built-in syntax highlighting option.
TF generates all the navigation and table of contents.
TF is designed to create a multilingual documentation. Apart from storing many versions of the same file and interface texts, it contains a simple tool to detect whether the "derived language versions" are up-to-date.
TF allows to generate the XHTML version very quickly, on a single page, as well as on many. We are also creating a special format for importing the manual to the database (to publish it online and for example, to add user comments).
TF packs your manual by default in the nice, green layout.

Although there haven't been any release so far, you can always connect to our new SVN and download the code from there. The link to the checkout commands is: http://svn.invenzzia.org/svn/typefriendly/trunk/ - we encourage you to test the script now. In the repository, there is a README file and a nearly finished Polish version of the TF manual. But don't worry. The first release will be available with the English version, too. It's much shorter than OPL manual, and nice to translate :).

Now, I think it's a good idea to show an example. The first one would be one of the files from OPT template engine manual that we develop, too:

Title: optNode class
ShortTitle: optNode
Status: abstract
Extends: library.optcodebuffer
ExtendedBy:
 - library.optscannable
 - library.optcharacterdata
 - library.optexpression

----
An abstract XML node class. It provides the basic support for the most important features, such as type and parent.

Class fields
------------
All the fields are protected.

 Name          | Type      | Description
---------------|-----------|---------------------------------------
 $type         | Integer   | Numerical type identifier
 $parent       | optNode   | Node parent

Available type identifiers:

1. `OPT_CDATA_NODE` - `optCharacterData`
2. `OPT_TEXT_NODE` - `optText`
3. `OPT_EXPRESSION_NODE` - `optExpression`
4. `OPT_ELEMENT_NODE` - `optElement`
5. `OPT_ROOT_NODE` - `optRoot`

At the beginning, we have a header with tags. There we define the exact title, and in this case also the dependencies between the PHP classes. Notice that we refer to the other classes by writing the identifier of the chapter, where they are described. Of course, there are additional tag versions, where we can write the class names directly, for example if we inherit from some PHP built-in class. There are more available tags. Let's say we want to make a "See also" section:

SeeAlso:
 - chapter.text1
 - chapter.text2
 - chapter.text3

Once the tag list finishes, we begin the exact content in the Markdown format. The author designed it basing on the formatting used in text files and e-mails (it can be said that he wrote a parser for a syntax that self-evolved :)). This means that the source text is really clean and easy to read. In fact, it is just a bit lesser comfortable than a parsed one. The problem is, if someone is accustomed to some wiki syntax, because MD not always works in this way (take a look at the table). But it is quite easy to switch. We use Markdown even on our website and I must say that it is a very convienient tool. I'm sure you'll find it in more Invenzzia products. There is only one big shortcoming - the only available output is XHTML. For now, you have to forget about LaTeX and the rest, but I can assure you that we plan to add it, too.

The most frustrating problem while writing a manual is navigation. The links "Previous", "Next", "Up" are added by TypeFriendly, we create the "See also" section by adding a tag, but what about clickable function and class names? I thought about it a bit and I invended a brilliant and simple idea. We have an additional text file, where we define, what text points to what. For example, we write there that `optClass::parse()` must always be a link to library.optclass.parse and that's all. Unfortunately, we haven't hacked Markdown in this way so far and the first release will not contain it yet.

TypeFriendly works in the operating system command line. We've tested it both on Linux and Windows and it works there without any problems. All we need is a PHP parser. Togethet with a simple syntax and built-in multilingual support, TF should encourage much more people to help in translations of your manuals, improving the base version and maybe even writing new outputs. Generating the XHTML version is really easy:

php ./typefriendly.php -l en -o xhtml ./path/to/manual/

Let's compare it to DocBook. The format itself is a bit longer, but relatively easy to learn. However, the conversion needs more tools. We must download the DTD, DocBook XSL Stylesheets and an XSTL parser. The choice is important, because fast and easy xsltproc will not highlight your syntax in the examples. On the other hand, the Windows users are f@#$ off if the author decides to write half of the processing tools in Bash. We don't have to look such examples too far. Just take a look at the PHP manual. Guess, what is it written in? :)

SVN is active!

Zyx — Mon, 30 Jun 2008 08:10:00 +0200

Unfortunately, the configuration of a version control system on our current server is not as simple as on Sourceforge.net. But now I found some time and ideas, how to make it work and finally... there it is, we have an SVN repository. It's available under the address http://svn.invenzzia.org/ - we still have to install a good browser. Today I'm going to upload the source code of the new OPL and TypeFriendly, a documentation generator almost ready to its first release. All the instructions, how to connect, will be published on the main site.

OPT requirements

Zyx — Sun, 06 Apr 2008 10:28:00 +0200

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

The optimizations implemented in OPT, mostly concern the main parser class and the compiler. The first one is the part that is loaded every time the script wants to use templates, so it must provide huge quality standards. There are no sophisticated algorithms, so the speed improvements are:

To minimize the size of the code.
To minimize the amount of points that try to access the hard drive.
To use the fastest elements of the language.

The point is this class must be as light as possible; I would even say: almost transparent for the script.

The situation is quite different, when it comes to the compiler. It is loaded from time to time, so it can be big and splitted for more files (of course without exaggeration). The key role is played by the limits set in the PHP configuration, because in the pesimistic situations, the compiler runs out of resources to complete the task. Unfortunately, some of the new features cost a lot, and if the users wanted XML tag parsing, they must face the consequences: every such tag requires its own node object in the document tree and they need some preparation tasks to be done. My role is to minimize the time and memory necessary to do this.

The elements that can be exhausted during the compilation are:

The stack
The memory

The algorithms used in the compiler operate on a data structure called tree, and the use lots of recursion. It consumes the stack, because the number of currently executed methods and functions grows quite fast. In PHP, the default limit for the stack depth is 64 and if you are going to use OPT, the worst you can do is to lower it to ridiculous values like "16" that would affect not only OPT, but also many other scripts :). However, every recursion has an imperative version, constructed for example by queues. Maybe it does not consume less memory, but at least it does not depend on the limits. Such changes have been applied to many compiler methods so far, but some of them still require my attention, because they are not so trivial:

Processing the tree by the instruction processors
Expression compilation

In the first one the situation is clear: we get a node of some instruction and want to process it. We find its processor and redirect the node to it. It generates some PHP code and decides, what to do with its children. By default, it wants to process them, too. Here comes the recursion and the process starts from the beginning. There are some difficulties. The algorithm is split over many classes, and the programmers may create their own. What is more, some instructions need to start the subnode processing immediately, because their next decision depends on the code generated by the children. Obviously, this eliminates queues. An elegant replacement could be made, if we had an access to the low level programming.

Let's take a look, how it affects the compilation process. We have a huge template, with the tags nested up to the level 30. OPT with the compiler can take another 10 calls, and in the deepest place we have a complicated expression with brackets. To sum up, the library uses approx. 45 calls from 64 available, which is more than 70% of the limit! I know this case is quite pesimistic and in normal life such HTML documents are very rare, but it shows, how demanding the compilation can be.

If we can't remove the recursion without ugly tricks which would be never accepted by the instruction authors, how we can get around it? The idea is not to remove recursion completely, but we keep it in some places. I use here the fact that the immediate access to the subnode compilation results is necessary only for some instructions, and for example the HTML tags do not need it at all. If we get a random node from the tree, we have a big chance that it would not need a recursion here. So, why don't we provide a dual version of this algorithm? By default, it is executed with a queue, but for more sophisticated needs, some nodes can switch it to recursion. Now it can happen that a tree with a depth 30 is processed in one single loop, with no recursion! I predict that in normal situations, the algorithm will consume only 3, 4 spare "items" in the stack, which is fully acceptable.

The second issue concerns the memory usage. It's not so tragic here, but we can notice a significant rise when compared to the OPT 1.x compiler, even with using some patents from that version. The most memory is consumed by the tree. I've measured some single nodes recently and the results were from 2 kilobytes for a single node to 3 kilobytes for a node with one attribute. When the instructions start to add the PHP code to the buffers, the things are getting worse, but it happens only in some nodes in the whole template. We can safe some memory here. The objects use various arrays, which are initialized just in the beginning, for example:

php
abstract class optScannable extends optNode implements Iterator
{
	protected $subnodes = array();

In most of the nodes, the arrays are empty, so it it no sense for them to exist all the time. I fixed the code so that it creates an array only when it is necessary. From the declarations, the = array() parts were removed. The effect is quite interesting. On a single array, we safe 400 bytes. The new results are:

Single node with no attributes: 1400 b.
Single node with one attribute: 2350 b.

The additional memory may be safed by releasing the huge data that will not be used anymore, for example the template content.

What do we have to remember, while using the new OPT, when it comes to the requirement issues:

With the terribly low limits, the compiler will always crash. I thing 16 megabytes for the script (the default limit) is big enough both for the compiler and the script.
The best place to run the template parsing is the end of the script. We can delete some unncessary data earlier to free some memory.
The templates using the inheritance are more demanding, especially when overwriting snippets, because the compiler must keep also the old versions in the memory.
The quirks mode will consume less memory (simpler tree - no XML tags), but it is not implemented yet.
The compilation is run once for a long time. During the normal execution, we can forget about the limit issues etc.

I think this note shows, how difficult the library creation can be. The key is to know, what we can use in current place and that there is also the rest of the script which uses the same memory and has its own requirements.