Zikula Blog

It's time again to summarize the direction of core development. According to the roadmap 1.1.1 has made a good progress in the meanwhile, thanks to Frank's holidays. If you are using 1.1.0 and want to get rid of some bugs, feel free to try out 1.1.1-dev from SVN.

Also we are working on the 1.2.0 version, for example some further ValueAddons modules have been outsourced recently and we did a little cleanup at the Settings page. Most remaining tickets are related to …t introduction. Bernd has already done much for that stuff in 2.0.0 and he is going to backport it soon. Furthermore we want to add some missin…onment details in order to reduce the amount of people having problems with installing Zikula.

There is also a 1.3.0 release planned which primarily collects several bugs and many feature requests for pnForm as well as the user management area.

Beside this 2.0.0 is evolving steadily: Frank merged the back…e Theme module and did even add a new admin block for simplified administration. PendingContent became a system module, but needs still a rewrite. In terms of security the SafeHTML outputfilter has been replaced by HTMLPurifier, also we added support for PHPIDS and a password strength meter.

Another topic is that Zikula 2.0.0 is going to introduce a new level of architectural changes, which is the focus of this article because some people requested information about the planning direction. So if you are interested in a quite detailed insight about what is happening there, read on

Perhaps you already saw some small impressions of 2.0.0 code at the coredev summary pdf presentation file which can be found in the core wiki. Let's shed some light on this.

Zikula 1.0 established a completely rewritten core architecture and introduced a powerful object library. This compound of useful util classes allows easy development of extensions and saves much redundant code. As soon as people get known with DBUtil and PNObject (ZObject in 2.0.0) they recognize the stunning improvement compared to the PN .76x codebase. In 1.1.0 this object library moved into the includes/ folder, while most of the old pn* files were merged into according util classes.

The object library has also a few disadvantages though. For example the overall performance is reduced by several factors, like a strong coupling of most util classes (which leads to that all of them are always loaded) and many generic services (e.g. the ObjectUtil functionality providing categories, attributes, default fields and metadata). This is a problem with big impacts and therefore one circumstance to deal with in the 2.x branch. One sub action of that is removing some unneeded parts of the objlib. But even then the simple addition of more and more features to the 1.x architecture would blow up memory limits at some point. Also as Smarty has many file system requests we have to take care for getting at least the other stuff improved.

The second important aspect is that Zikula 2.0.0 requires PHP5. This includes several different types of tasks: first there are some language-oriented changes, like updating visibility modifiers and removing unneeded references. Also we did a separation between ZObject and ZObjectArray by introducing a common parent class called ZObjectCommon and installed an auto class loader component.

Beside these quite clear changes for several reasons there is a greater effort required to introduce real object orientation by design. In this context real is meant in this way that objects are used. Let me explain the basic concepts and advantages briefly also if you already know it. The object-oriented programming paradigm offers three mighty means for managing software complexity.

First it allows clean data encapsulation within classes and well-defined access from the outside. This does not only reduce coupling grade potentially, but also decreases redundancies and subsequent changes. In general a class can centrally store code which would occur multiple times else. A Zikula-specific example for that is ZSystemModule which is a subclass of ZModule setting the base path to system/ instead of module/. You can't estimate how often this is determined in the whole core

The second powerful mechanism OO is offering, is called polymorphism, meaning that objects are exchangeable within a specific view. An interface defines such a "role" and can be used as any other object type. So for example we could create an interface called IOutput defining a method echo(). If we then have a list of objects (modules, themes, users, whatever) we could use it in a loop like "if ($myObject instanceOf IOutput) $myObject->echo()", whereby it is not relevant if $myObject is a module, a theme or something else. So regarding their IOutput role, all these objects are exchangeable. Interfaces are even more powerful, as they can be inherited and every class can implement multiple interfaces to be used as different roles at once. If we have something like "class Foo implements IOutput, ISortable" then the instanceOf operator will return true for Foo, IOutput, ISortable and certainly Object. Interfaces become especially important if certain aspects have to be forced. In the real world you know that from your usb devices: there are many different things which can be connected to your laptop, but all have the same usb interface. So if we for example want to ensure that all profile or message modules behave the same way, they will have to implement an according interface in future. The core itself calls simply the interface methods then.

The third thing to consider in object orientation is inheritance, for both classes and interfaces. Carefully applied this can be a nice approach to disburden third party developers. For example the ZModuleInstaller class is intended to serve as a basic class for module installations. At the moment it's initialize() method simply sets up all tables and modvars the given ZModule instance provides. This means that modules which do not need to perform special actions don't have to extend it. If you look at the EphemeridsInstaller example you can see that only the upgrade() method has to be implemented, as initialize() and delete() are both covered by the parent class. Cool: less redundancies, less code There will also be a corresponding ZModuleInstallerInteractive class later certainly.

There are several different concrete design principles and best-practice patterns available, but this would wander too far from this subject. Let's return to Zikula!

The current util classes provide static methods like functions which does not fit to the object-oriented way of thinking. For example all DBUtil methods like updateTable(), changeTable(), insertObject(), aso. expect a table name as a parameter to know which table is worked on. In contrast a ZDBTable represents a table knowing it's properties and functionalities (remember data encapsulation). This is one main reason why new classes are…n Zikula 2.0.0 step by step. The other reason is that we are going to be able to save about 60-80 percent code of a module in 1.x, which improves maintainability significantly

At the moment most of these classes is not ready yet, but drafted. Migration is going on gradually, as we have to take care for backwards compatability. Thus, we added a simply bridge to the DBUtil methods: if ($table instanceOf ZDBTable) { new style } else { old style }. This is the first step. The second step is then to revert the whole logic: methods will move into ZDB* classes (for example DBUtil::updateTable() becomes $myTable->update()), while the DBUtil method will use ZDB*Legacy classes. Let me explain that with ZModule and ZModuleLegacy which is more easier: the core simply uses the ZModule class a module has implemented. If no class is provided, ZModuleLegacy is instantiated with the module name as a parameter. The old code then lives within ZModuleLegacy, reading out pntables.php, calling pninit.php and so on. With this proceeding we cope with establishing a new clean object-based code and encapsulating the old functionality properly.

One might argue that the introduction of objects reduce overall performance, as method calls are slower than function calls. They are indeed slower, but with the mentioned objlib decoupling we should win below the line. One example from a current DBUtil method is: $idFieldName = (($table instanceof ZDBTable) ? $table->getPrimaryKey()->getName() :
(isset(self::$tables["{$table}_primary_key_column"]) ?
self::$tables["{$table}_primary_key_column"] : 'id')); At the moment we have two method calls here, but later this method will live in either ZDBTable (which would be one method call less) or in ZDBColumn (which would be no method call at all).

ZModule, ZModuleInstaller, the ZDB* classes and a few others are the first step. Later more classes will follow, for instance for calling and embedding module functions (something like ZAction, ZTask or ZCommand). Together with some interfaces this will save so much code that you will jump up and shout hooray. For example imagine a ZActionListObjects action accepting a ZObjectArray and a few parameters. Smile now

So as you see there is hot stuff going on. Not everything will be touched in 2.0.0 though, for now only everything related to the …e architecture is focused. So for example a ZUser class representing a Zikula user in a comfortable way is something which will probably become part of a 2.1.0 or a later 3.0.0 release.

Beside these fundamental changes there are several minor additions. Let me simply list a few of them: there is a new ZObjectFactory base class which is intended to be implemented to simplify instantiation of module objects. ZObject is going to be adapted to the … active record functionality.

Also exceptions are …ing introduced. Their advantage is the separation of calling and called code. If person X writes a class, he knows which error may occur. If person y uses this class, he knows how to treat errors. We created an initial set of own exceptions for different areas. A few of them are inheriting from exception types PHP5 is offering (example: class ZInvalidModuleException extends InvalidArgumentException). With exceptions we can also establish different handling possibilities depending on those error types. But before they will be used in the whole core, some redundancies have to be solved first.

Another subproject of 2.0.0 is the consistent use …ing guidelines with the help of the phpcs project of Sebastian. Although there are not many checks existing yet, we are making a qu… good progress. Regarding testing there is even much more planned, but this is for another article. Important to emphasize it that this further improves stability and reliability of the core. Object-oriented code has also the positive effect of improved understandabality and readability. For example a line like "if ($myModule->conflictsWith('Dizkus'))" isn't really hard to read, is it?

I hope this summary could show up that we are doing a combination of challenging the mentioned performance problems and further improving maintainability, reusability and flexibility for module developers. That is really not trivial and it will need some time, but keep cool: 1.2.0 and 1.3.0 will keep you occupied If you have any comments or questions about these evolvements, please drop me a line.