This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Blogs » Terry Duivesteijn » Road to eZ Market (2): contacting eZ,...


Road to eZ Market (2): contacting eZ, decisions and implications

Friday 11 May 2012 4:08:48 pm

  • Currently 3 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Last time I wrote about the first steps we took to launch the extension ‘eZ Multitasking One’ on the eZ Market. In this blog post I will describe why we chose to develop our extension as much as a self-contained product, relying on the eZ Publish kernel. But first, did you perhaps join the webinar of the eZ Publish Enterprise 4.7 ‘Etna’ release yesterday? Then you should have seen a glimpse of our extension in the presentation, being described as ‘revolutionary’ for eZ Publish, or as the news-page of eZ describes it: ‘The possibility of editing and working on multiple articles or content items at any given time revolutionizes the way eZ Publish Enterprise clients can operate freeing up operators to concentrate on the quality of content creation which is their core business.’ Yes, that made me proud, and also gave me extra energy to write this blog post today.

Touching base with eZ

We met with eZ in Dortmund July 2011 to discuss whether they were interested in our extension for the eZ Market, and we wanted to be sure that nobody else was already working on an extension similar to what we had in mind. Everything was  rather informal and we got an response that they liked our idea and welcomed us as a new contributor to the eZ Market. Recently eZ has articulated and improved this pre-development procedures (described by Christian Pfeffer Gjengedal (PDF) at the eZ Conference in Lisbon in February of this year).

We received an ‘eZ Market – Certification Kit’, a compilation of files that contains the guidelines for development and for the user interface. In addition there was general information about the eZ Market and the certification-process itself. In order to launch a product on the eZ Market, the extension will be certified by eZ Engineering to see if the main criteria as described in the development guidelines are met. If you are a contributor to the eZ Publish kernel and/or extensions, you are probably already aware of some of the development guidelines. You can find them by digging in the community website (1, 2). The development guidelines in the certification kit contains global guidelines about naming conventions, documentation requirements, physical setup of your extension (directories), required basic files (README, SUPPORT, NEWS, ezinfo.php, extension.xml, etc.).  


In my last post I gave a list of features we wanted to integrate in the extension. To integrate these features in our product, we had to find out what we could realize with the existing functionality in the latest eZ Publish Enterprise release that was available. At the time it was eZ Publish Enterprise 4.5. Since the REST API was just released, we had to make a decision whether or not to use the eZ REST API.  We concluded that it still was too much in a state of flux for us to confidently use in production. We decided to make our own communication interface. Also, it was clear to us that a great deal of the eZ Publish’ admin2 templates could not serve our needs because, for efficiency reasons, we wanted the programming to be separated from the templates as much as possible. Basically what it boiled down to is that our extension would be a self-contained product, relying on the eZ Publish kernel and some of the admin2-templates, but the majority would have to be custom-made.

This had a lot of implications for the entire setup of our extension. We had to make our own RESTful API and corresponding jQuery library for the front-end. And because the default administration interface didn’t suit our needs, we had to either override the default interface (which we obviously didn’t go with) or had to make a true ‘extension’ with its own module views and siteaccess. Even though we introduced a new interface, new API and new interactions and features, the product still uses the default content/edit module assisted by our own API calls. This way we accounted for existing security and logic in the eZ Publish kernel, while adding efficiency-features in pre- and post-editing steps.

In my next post I will describe the choice for the front-end and back-end technology we used.

Proudly Developed with from