Here's a little comparison between a specific project designed in Java with some common framework and the same project realized with eZ publish.

Persistent layer

The persistent layer allows developper to use an abstract logical layer in their software to avoid manipulating specific instructions to get data from the data source. For example, you would like to access some data in a DB2 database. The first idea is to use APIs of your favorite language to access data through a SQL query, which means that if you decide to change your data source (another database or any storage system), you will have to change the access functions to your data. So, you can put a logical layer between your data source and your work oriented objects. By the way, you will avoid manipulating directly instructions to get your data (like SQL queries, file parsing, or whatever) and then only use objects instead of raw arrays of data.

The most common persistent layer for J2EE is Hibernate. The use of this one is really simple, you only have to set up a configuration file hibernate.cfg.xml and to indicate the mapping you would like to have between your data source and your objects. Then you have to create the classes you will use to access your data. All your relations will be managed by Hibernate. It's a bit restrictive because for complex applications because you will have a lot of classes to write. Fortunately, there's some software you can use to generate all directly.
In eZ publish, there's also a persistent layer which is divided in two parts. The first part is concerning the data connector eZ publish uses to get and store data from the data source : it's very similar to a JDBC connector. You have to specify some configuration in the site.ini.append.php for your site access like the DatabasImplementation (the connector) you would like to use. It allows you to access an object in your php file.

Then, you can run some queries like :

To access the data you would like to get back.

But it's only relying on connectors and not on persistent layer. So, we can extend that using the eZPersistentObject class wich allows you to use several methods to access the objects stored in the database not only as array of data but as a complete object. You can find some examples on the way to design this here.

The MVC concept

The MVC (Model, View, Controler) concept is a design concept used to design any kind of software. The main goal of this concept is to separate the data and all the process you have done to get it and to display it. For HTML pages, it's easy to understand. For example, have a look this HTML page :

The information content wich is important is the text nested in the paragraph and the path to the image. In an old school way to design website, we would have put the HTML page directly on the web server, but as we use dynamic technology such as J2EE or PHP or .NET, this page will be generated at the end of a very simple process for the most of the time. So, if you try to reach a page throught you browser typing an URL, if there is a dynamic server on the other side, your call will be transformed in a call to a certain method in a certain class somewhere on the server in order to generate HTML. And there is two points about that.

The first is, because to the use of a persistent layer, you won't put hard-coded data in your classes. And this matters in the two ways of sending data : from the server to the browser (Controler) and from the browser to the server (Model). In the Model, you will do the whole tests before saving, updating or removing your data.

The second is an extension of the first point, you will put all the data you would like to put in your classes in another object, and then in a data storage. For example, if you have some constants or messages not linked to the content but to the process you are running, you will keep them in some place and not necessary in the same than your content. You can also customize your code like adding some settings administrators can modify to change the behaviour of your application.

There is a direct impact in using this concept : your code is cleaner so you can modify it more quickly. The second point is very usefull too, because by this way you are adding some scalibility to the application and you improve it easily and quickly.

The other point on using an MVC framework is to separate the way you are displaying your information and the way you are controling it. Controling means running some tests on your data to decide wich view to display to the user.

For J2EE application, we use the Struts framework wich is the most advanced MVC framework developped in Java.

For eZ publish, a kind of MVC is defined through the use of modules and functions concepts but you can't use it for another application, its' nested in the eZ publish kernel. However, you can use it to design your own processes by creating some extensions for eZ publish.

And over all ?

And finally, I was wondering if another design concept / framework can be used in these kind of application.

In the Model layer of your MVC, you can divide this step in several steps.

It's common to use a DAO layer, static class, which will use the persistent layer to save / update your data or just store the queries. Then you can use a Services layer to separate the operations done on the data regardless to the way we are storing it.

For example, if I would like to save a User in my application, I will create a class for the User Object (with the attributes of the user and getter / setter methods), a static class for the Data Access Object (to store a user, modify it and search a specific one), and then a User Services static class to put my model processes and rules (if the user does not exist, I will create it).

We can go further and create a class to link your forms to an object and so reach directly all the data submited by the user in an object.

In eZ publish, the DAO Layer and the model class are merged due to the eZPersistentObject class. We don't have Services classes but for some kind of datatype, for example ezimage, we can have some classes to handle the data (ezimagealiashandler).

In J2EE application, the data entered by the user are stored in "Beans" object to ease the verification and process of the form.

Conclusion

Technologies are close due to the use of the same design concepts but the way it has been developped is a bit different and not with the same complexity or strictness.

By the way, designing a project in J2EE or in PHP would be conceptually the same but is easier with eZ publish due to the bundle functionnalities. Never the less, it's not fully exportable to another project which is demanding fewer functionnalities. This why eZ Systems is supporting the eZ Components project.

The other point which is very important is the integration with the application server which serves all this. Is there an asset to use a webapp server like TomCat to nest an application through servlets ? Or is it better to give full freedom with appliction "I'm running everywhere" with servers using PHP ? May we think to a PHP application server ?

As usual for a conference, I spent almost all of the time I was at Go Open 2008 talking with people (and occasionally talking at people.) The following is a list of people I talked with (or listened to) along with the interesting or exciting things that they shared with me or that they're working on: The [...]

Birthday Datatype Changelog:

• Added error message for non valid dates
• Added age calculation ($attribute.content.age)
• Translated some strings to german

I just release Xdebug 2.0.3 which addresses some minor bugs. The main new thing is PHP 5.3 support. You can get Xdebug through PECL (pecl install xdebug) or from the Xdebug site.

Our design partner OneZero has been so kind to design this issue for us and give us input in how to utilize eZ Publish and design. You can also read more about...

.flickr-photo { border: solid 2px #000000; } .flickr-yourcomment { } .flickr-frame { text-align: left; padding: 3px; } .flickr-caption { font-size: 0.8em; margin-top: 0px; } Demonstration against OOXML, originally uploaded by Martin Bekkelund. Blearily stumbling down to breakfast, I was confronted with a mix of lukewarm meatballs, easy listening radio — both of which are common enough to [...]

Demonstration against OOXML, originally uploaded by Martin Bekkelund. It is a day after the Go Open conference in Oslo and I am still holed up in a hotel nearby. Blearily stumbling down to breakfast, I was confronted with a mix of lukewarm meatballs, easy listening radio — both of which are common enough to encounter in [...]

In an eZ Publish site structure, there are often nodes that hold information shown as a part of the full view of a different, master node. Showing the full view of the former nodes themselves or getting them as search results is usually unwanted. This is common in forums and articles with comments. If you have worked on a large eZ Publish project, you have probably used such nodes without referring to them by a specific name. This article explains what we call “helper nodes” and also explores the template and content model issues involved, relating specifically to search results.

I've been working on some code, while developing on PHP 5.3. The code resembles the following structure:

<?php
interface ezcSearchQuery
{
    public function limit( $limit, $offset = '' );
}
interface ezcSearchFindQuery extends ezcSearchQuery
{
}
class ezcSearchFindQuerySolr implements ezcSearchFindQuery
{
    public function limit( $limit = 10, $offset = 0 )
    {
        $this->limit = $limit;
        $this->offset = $offset;
    }
}
?>

No problems at all while development, no warnings, no errors. Now when I deployed this on a PHP 5.2 machine it bombed out, with the following correct message:

Fatal error: Declaration of ezcSearchFindQuerySolr::limit() must be compatible with that of ezcSearchQuery::limit() in /tmp/index.php on line 11

And this really sucks. I made a mistake in my code (wrongly implemented interface) and I get no warning (not even E_STRICT)... and then deploy it and it bails out on me. We can't have this. We need warnings (actually, it should be E_FATAL) for those cases in order to avoid problems. I don't know how this check got removed, but it should be put back in ASAP!

Day two of Go Open is just about to get started. Already, there's a good amount of coverage in the Norwegian press on the event. I have made a pitiful attempt to translate the titles of the articles, mostly for the amusement of my Norwegian friends. Alexander V. Røyne blogged, go open day 2008 1: Chris [...]