|
|
|
Posted
over 2 years
ago
by
Zyx
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
... [More]
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. [Less]
|
|
Posted
almost 3 years
ago
by
Zyx
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
... [More]
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. [Less]
|
|
Posted
almost 3 years
ago
by
Invenzzia
Invenzzia Group is proud to announce the availability of Open Power Template 2.0.6. This is a bugfix release that fixes four bugs. It is available in our Download page and the changelog is available here.
|
|
Posted
about 3 years
ago
by
Zyx
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
... [More]
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. [Less]
|
|
Posted
about 3 years
ago
by
Invenzzia
Invenzzia Group is proud to announce the availability of Open Power Template 2.0.5. The new version fixes some small bugs, and brings a couple of new template functions and a new data format. It is available in our Download page and the changelog is available here.
|
|
Posted
about 3 years
ago
by
Invenzzia
This tutorial explains different template modularization techniques available in Open Power Template and shows how to use them to create a flexible template rendering environment for a typical web application.
|
|
Posted
over 3 years
ago
by
Zyx
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
... [More]
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. [Less]
|
|
Posted
over 3 years
ago
by
Invenzzia
Invenzzia Group is proud to announce the availability of Open Power Template 2.0.4. The new version fixes several bugs found in the library. It is available in our Download page and the changelog is available here.
|
|
Posted
over 3 years
ago
by
Invenzzia
The Open Power Template syntax is based on XML. This leads us to a set of instructions helpful in managing the produced XML code, creating attributes and tags and the whole process is a bit different than in most of the template engines. This article
... [More]
is going to show you, how to use the available tools and how to manipulate the generated output HTML code. [Less]
|
|
Posted
over 3 years
ago
by
Zyx
I have published a new tutorial for Open Power Template today. It shows how to use sections and data formats for OPT. I chose this topic, because I noticed that some users have problems with understanding them and decided that an extra tutorial would
... [More]
help them. Before the end of the year, I'll try to write one more text about working with XML in OPT. The article is available on Invenzzia website both in English and Polish language versions. [Less]
|
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.