Voici un compte rendu du eZ developer day du 17/04/2008 qui s'est déroulé dans les locaux de Sun Microsystems réunissant une cinquantaine de développeurs intéressé par le CMS eZ Publish . Nous avons tout d'abord eu droit à une première présentation de la stratégie "Open Source" de Sun. Rien de très intéressant techniquement parlant, si ce n'est quelques fonctionnalités avancées d'Open Solaris comme le système de fichiers ZFS ou la solution de virtualisation et une volonté affichée avec l'ouverture de Solaris de concurrencer les distributions Linux autant au niveau professionnel avec des niveaux de support avancés qu'au niveau communautaire.

La suite était heureusement nettement plus intéressante. Comme en octobre dernier Paul Borgermans nous a présenté la roadmap des différents produits eZ (eZ Publish, eZ Components , eZ Flow, eZ Find , ...). Le moins qu'on puisse dire est que de grosses évolutions voire des révolutions sont en marche au moins au niveau d'eZ Publish.

La version 4.1 d'eZ Publish

Cette version devrait voir apparaître le très attendu Online Editor basé sur TinyMCE bien plus configurable et souple que l'actuel. La compatibilité avec l'existant sera assuré de manière transparente. Cette version verra aussi le retour de la compatibilité avec Oracle, le support de Solaris 10 ou encore une fonctionnalité d'expiration des mots de passe développé par un partenaire.

Une extension fournissant un flash permettant l'upload massif sera également fournie. La démonstration était vraiment bluffante, ce sera une alternative très intéressante au WebDAV , protocole qui manque cruellement de client fiable en particulier sous Windows.

La version 4.5 d'eZ Publish

Cette version verra beaucoup de changements internes selon 2 axes principaux

1. L'intégration des eZ Components
2. L'amélioration de performances

Le second étant en partie remplie par le premier. en vrac les nouveautés annoncées sont les suivantes :

• allègement du code kernel en déplaçant plusieurs fonctionnalités dans des extensions permettant leur activation/désactivation simplement
• nouveau système de template et donc de surcharge (override) bien plus performant. Paul citait un exemple d'un template complexe qui s'éxécute 20 fois plus rapidement avec le nouveau système !
• amélioration du système de cache pour le rendre plus granulaire. Une possible implémentation de la norme ESI (Edge Side Includes) a également été évoquée pour être compatible avec Akamaï ou le reverse proxy Varnish .
• support de IIS avec PHP en mode FastCGI ainsi que de MS SQL. D'autres SGBD pourrait également être supporté l'écriture de la couche d'interface nécessaire
• introduction des "object states" personnalisables permettant de brancher facilement l'exécution d'un processus de workflow externe
• refonte du fichier index.php dans le but de l'alléger et de le rendre plus performant mais aussi de pouvoir y brancher l'exécution d'un script sans passer par toute la pile d'eZ Publish lorsque le besoin de performances est important
• réécriture du système multi-lingue et des URL alias car le code est actuel est complexe et est basé sur des opérations bit à bit en base de données ce qui compromet la portabilité sur différent SGBD
• "dé-normalisation" de la base de données, en particulier dans un premier temps la gestion des utilisateurs permettant de supporter plus d'utilisateurs. La "dé-normalisation" au niveau des contenus a également été abordée mais reste pour le moment un projet à plus long terme...

ouf ! voila déjà une belle et ambitieuse liste rien que pour eZ Publish ! Cette version devrait paraître avant la fin de l'année.

eZ Find, eZ Flow, eZ Components

eZ Find 1.1 apportera la recherche par facets dans le courant du second trimestre 2008. La version 2.0 sera une réécriture complète via le composant Search des eZ Components de manière à profiter de l'ensemble des fonctionnalités de Solr .

De nouvelles version d'eZ Flow et d'eZ Components sont annoncées pour la eZ conférence en Norvège au mois de juin . Enfin, eZ Flow 2.0 est également annoncée pour la fin de l'année.

BarCamp !

L'après midi s'est terminé par un barcamp axé sur les questions apportées par les différents participants. Chacun a pu échanger sur ses "recettes de cuisine" eZ Publish, je retiens plusieurs points très en vrac :

• PHP 5.3 apporte des gains significatifs de consomation mémoire
• Le mode cluster d'eZ Publish pose souvent problème (d'où les améliorations annoncées). Des solutions de contournements ont été mises en place par plusieurs prestataires.
• La gestion des utilisateurs est parfois problématique (volume, synchronisation LDAP, ...), là aussi des améliorations sont en cours.
• Enfin au niveau du volume de contenus possibles dans eZ Publish, Paul explique qu'avec du bon matériel eZ Publish est capable de gèrer un million de contenus sans vrai problème même si c'est dépendant de l'organisation de l'aborescence.

Bon au final, mon sentiment sur cette après midi fort instructive est que le développement d'eZ Publish tente de combler les lacunes au niveau des (très) gros sites autant en terme de volume qu'en terme de performances.

Snack Culture

Last week, I went to the eZSystem's Partner Day which was organized at Apple France headquarters. Vincent Bellissen's first slide was about Snack Culture, a new consumption habit based on bite-sized products. Minimal invest and maximum entertainment. You want to change, you can and it is easy.

A typical example is the success of the iTunes music library : once registered in the iStore, you can buy music files in just few clicks. The Amazon website allows too to buy books or dvds in two clicks maximum (one to login and one to buy).

So the consumption habit has evolved in the way that you can enjoy little part of a product instead of the full product. If we check the ratio part of product / price, we can see that the producer gets always great benefits. It's not new, you may buy a big pot of mayonnaise for 10€ or a tiny one for 3€ but you won't get the third of the big pot. What has changed is the way we can buy it, the product's availability and the way we can use it. You can check your mails while waiting a friend in a bar, watch a movie clip in the tube or even surf the net during a fly.

However, it's a bit threatening. I was thinking that in ten years, children won't read books anymore...

99 Francs

Still digesting this inner revolution, I watched the day after a French movie called “99 Francs”. The story is about a creative publicist who is working in the larger advertisement company in France and who has some issues with girls, drugs, his boss and the whole meaning of his life... I guess it is a good movie and it makes me wonder some things.

Our consumption habits are also enclosed in our today life. We are more receptive to advertisement using some classical symbols and values than original scripts and out of sequence art design. So, if we change the way to consume products by adding mobility and specific parts of products, may be we can break free from this chasm of consumption, classical one.

Moreover, I thought that it might be a catalyst for new shape of art and techniques. With smart phones, we will be able to add high enhanced applications as interactive games, shared software and other funny stuff (video chat or whatever).

Co ?

So, this is what we do. Causing people to buy our products or our services. We are creating desire around functionalities and freedom for a more or less convinced set of people.

The limit is what we can do to be pertinent : what functionality can I imagine that will be sold in the real life ? The business is restricting the scope of our ability and by this way only focusing on what is really important : users need.

That's why changing our consumption habit may change the way we are doing things. We may experiment some new techniques as the impact on bite-sized consumption is very thin.

It took me fairly long time to figure out what particular tool available from PHP in my custom software and website implementations was missing from eZ Publish... but I finally got it. It's the ability to dynamically, flexibly cache variables, understood as operation or logic results, stored in a reusable form. Naturally, there is no significant need of caching simple variables defined directly within the pagelayout, just like these:

However, it gets worse not being able to cheaply store an array of ten values, whose fetching/generating cost was over fifty or one hundred SQL queries, several files accessed in the file system, etc.

Problem

The problem seems quite straightforward - out of many caching techniques and layers in eZ Publish, only two are universally useful: the viewcache and the cache-blocks. Unfortunately, both of them store presentation layer results rather than data, and both are quite independent. As a result:

1. Whenever you crave for variables that will be used by several cache-blocks in the pagelayout, they must be placed outside of cache-blocks themselves. Don't get fooled by the top cache-block apparently holding the variables used further on - it's a coincidence. This may only work if all expiry times are equal for all the blocks and no subtree expiry is ever used (or you've used bugged eZ 4.0.0 for half-a-year, where subtree expiry is simply broken and it's easy to take it as the default behavior), provided that the blocks never got desynchronized. The point is: variables must be kept outside cache-blocks and they will not be cached.
2. The module result gets generated before the pagelayout, so there's little reusability between their vars.

So what's missing?

My idea is a cache layer halfway between logic/data and the presentation layer. It could be a variable-dedicated cache-block equivalent (maybe a var-block?).

Example: Imagine a website that for each of its node views should be able to access both current node data (data map) as well as root node data in order to make some decisions, calculations, etc. Further, the data could be required by at least three of its cache blocks (with different expiry times, expiry rules and "uncomfortable" locations within the pagelayout). Today that sort of combination requires a substantial...

The var-block as I imagine it would have expiry settings similar to cache-blocks: subtree expiry, expiry ignore, expiry time and a flexible key management. In order to prevent frequent file system access, var-block could serialize variable collections rather than just singles. An additional "collection name" parameter could help organize the blocks within the pagelayout.

Please let me know what you think.

Here's the prototype:
http://ez.no/developer/contribs/template_plugins/self_var_cache

Back after a longer while... wasn't on holiday, though ;)

About a week ago, while developing my fifth or tenth extension with its own, custom caching layer, I caught myself trying to clear that cache with eZ standard "Clear cache" button. To none of my surprise, it never worked, but after few attempts I decided to see why ;)

The Fine-grained cache control in the administration interface turned out to be a definition-type of array - easy enough to be made extensible with some effort. Why should a developer be in need of creating custom tools then? Let's hope the team picks up the idea soon:
http://issues.ez.no/IssueView.php?Id=12860&activeItem=3

The PHP Vikinger unconference will be held for the third year in Skien, Norway. Just like previous years it follows directly after eZ Systems conference which puts this year's PHP Vikinger on June 21st, the longest day of the year.

Flickr features some pictures from previous years. And PHP Norge has a report from last year. Let me know (through the e-mail on the PHP Vikinger website) if you're interested, and if you want to suggest topics.

Polish eZ community has met during the first official eZ Developer Day held in the country. Up to thirty people showed up, representing eZ partners, independent developers as well as users, both experienced and potential. Many of the participants were active Polish eZ Community members. eZ Systems was represented by Bård Farstad, co-funder and CTO (Chief Technical Officer) and our native system developer Łukasz Serwatka.

The meeting, which was held in the heart of capital city of Poland, included the introduction to eZ Systems and their flag products, including eZ Flow (both functional and technical demos), the discussion on eZ Publish roadmap and its future releases.

The community had a chance to present their recent implementations as well as share and discuss their problems or requests (I hope we didn't kill Łukasz during this part, as we tried to clear up issues that had been awaiting "closure" for quite some time).

Bård attempted to provoke some community commitment, so that it grows stronger and bigger, but I'm not sure how much response that would get. It got little while there, but there might be some follow-up. Seems like the active will remain active in their ways anyways.

Personally, I am very glad that we had this meeting. Maybe there was too little technical/developer detail, but everyone had an opportunity to bring things up... Maybe it lacked some social part, during which the community would get to know each other little better and discuss things in a more informal, open way. One suggestion though: make that a weekend event because socializing for most people in Poland hardly ever works during the weekdays! ;)

Still trying to find ways to improve eZPublish, I've thought about a simple process to resize pictures without having to download the picture, to resize in whatever image software and then, upload it again in eZPublish.

My aim is resizing and not scaling. It means that we are losing some information by cropping the picture that we are not losing by resizing. I'm just specifying this point because it's not a extension of the image.ini / image_class mechanism, but a new functionality which allow the user to cut himself a square in his picture. I guess a picture of the result is more obvious :

You can download it as usually on ez.no.

It uses a JavaScript library coded by David Spurr and the Scriptaculous library.

Still trying to find ways to improve eZPublish, I've thought about a simple process to resize pictures without having to download the picture, to resize in whatever image software and then, upload it again in eZPublish.

My aim is resizing and not scaling. It means that we are losing some information by cropping the picture that we are not losing by resizing. I'm just specifying this point because it's not a extension of the image.ini / image_class mechanism, but a new functionality which allow the user to cut himself a square in his picture. I guess a picture of the result is more obvious :

You can download it as usually on ez.no.

It uses a JavaScript library coded by David Spurr and the Scriptaculous library.

eZ Systems has included in their last release of eZ Publish a client for the Red5 video streaming server.

The documentation is a bit short and you don't necessary have all the elements to complete a full installation. After two hours of hanging about, I succeeded. :-D

Apache configuration

About the Apache configuration, you must add the following lines :

The first two lines are declaring to Apache the use of port 100 and that some virtual host will listen to it.

The second part is the virtual host as well, what I've added is the "Allow From All" directive that forbidd everyone to access the video. We can tune that.

Content configuration

The Red5 flash client is set up with the content published. In the eZ Flow site package, you have a content named "Live Recorder" which will support the recoder and which can be configured by editing its content. We have three attributes:

• Name : the name of the content : whatever.
• Stream Server : it is the URL to the Red5 server. The protocole used is RTMP (watch out the spelling) and you must finish it by a slash :

• File Server : it is the URL of the Apache file server which deserves the saved files. It's not streams/streams like in the screenshot.

And then you plug your webcam and you can start to make some funny films... live !

Conclusion

This feature is very powerful and stunning, however, I didn't find how we can put a live stream online and how we can list all the video we have taken.

Red5 Wiki

Main concept

A year ago, I was working on a project where we were confronted to a certain problematic. We had a lot of classes which really looked like each other and had the same schema of class. So, when we had to modify a class because an attribute was missing or not in the right datatype, we have been obliged to modify all classes and it's very very long when you've got a lot of content types. We were thinking at a solution : creating a class wich willl be a parent class for all the other classes. For exemple, your customer is selling furniture products via the webshop and here is a detail of how this solution could be applied :

• You create a class Furniture Product with those very generic attributes : Name, Description and so on.
• Actually, you have three types of furniture products, Table, Cupboard, Settee. In the normal way, you will have to create three different classes with common generic attributes and specific attributes. There, you will just create a class with the specific attributes, and choose via a list of classes from wich one you would like to inherit.
• After that, when you are editing and publishing content, the content schema is based on the merge of the parent class attributes and the specific class attributes.

Implementation

To realize that, here's what I was thinking about :

• Modify the SQL schema of the ezcontentclass table to add a integer attribute called parentclass_id.
• Modify the kernel/classes/ezcontentclass.php file to add parentclass_id to the definition of the object.
• Modify the kernel/classes/ezcontentclass_attribute.php file to process all the attributes, main class and parent class attributes, when we use a function.
• Modify the design/admin/templates/class/edit.tpl file to add the list of classes who can be parent.
• Modify the kernel/class/edit.php file to save the information.