This is my Mozilla Foundation report for February 3rd to February 9th, 2008. See the weblogs of David Boswell, Frank Hecker and Gerv Markham for additional reports. Much of this week was focused on participating in SCALE 6x, as well as traveling to and from the event, and preparing for other events. Projects for the Week Events SCALE 6x: [...]

Disclaimers usually go at the bottom of a post but because this one is quite lengthy I've decided to put it at the top. Mostly the stuff I post here is of a technical nature, but this time I'm posting an option piece, and as such it is full of wild speculation, personal thoughts, suggestions and of course opinion, all of which may have no basis in any reality other than my own.

You are here - the current state of play

I've been using eZPublish 4.0 since the beginning of the year. It's not quite what I envisioned when the rumbling of version 4.0 first started, oh so long ago, actually it's nothing like what I imagined.

Hence the title of this post. Initially Vista (Longhorn) was slated as a "minor step" between Windows XP (Whistler) and Blackcomb. However it gradually took on many of the features slated for Blackcomb. People got excited, but it's release was delayed several times, the developers were given other priorities and finally development started afresh based on Windows 2003 server and a limited feature set.[1] When finally released the general consensus seems to be one of disappointment or at least significantly underwhelmed.

Over time there has been quite a bit of excitement of what a new version of our favourite CMS might provide. Given the quantum leap in functionality between eZ Publish 2.0 and 3.0 who knew what unimaginable ecstasy version 4.0 would bring! However time marched on, PHP4 end of life was announced and eZ Publish 4.0 became a port of eZ 3 to PHP5 (continuing the community effort by Paul and Kristof).

Now this is not a bad thing, on the contrary it's the best thing that happened to eZ Publish in recent times (including the Online Editor in the distribution would be a close second).

At the local PHP meetup I would get strange looks because I was still using PHP4. I could get people excited about eZ Publish but people soon lost interest when told that it required PHP4 and a specific version at that. No matter how good the product sounded it's was hard to get people interested about something that had "special requirements". "None of the other PHP CMS have those requirements" was the standard response. It was impossible to get a foot in the door. Hopefully now with PHP5 support more people will be willing to try eZ Publish.

PHP5 support also makes it easier to get eZ Publish into corporate environments. RedHat seems to be the Linux distribution of choice in the corporate world (at least here in Australia) and it's lack of support for php4.4 has meant that in situations where we were the "application provider" we either had to convince the systems people to install the newer unsupported (by RedHat) version of PHP or do it ourselves. Of course this just created a bunch of issues around support (of the custom PHP) and called into question the choice of eZ Publish as a CMS platform.

Oh yeah, eZ runs faster under PHP5 as well!

Three cheers for eZ4.0 on PHP5!

eZ Components to the rescue

I spend much of my time working with eZ Publish as a framework by coding extensions that merge existing data sources into a CMS managed environment as well as creating fully fledged applications that run parallel to the CMS. When I learned of the eZ Components project and that it would from the basis of the new eZ Publish version I was very happy.

There are a bunch of subsystems in the current version of eZ Publish that are tightly coupled with the main content module that makes them pretty difficult to reuse in custom modules. Two that come to mind are the Image system and the Rich Text/XML Block Datatype. It seems such a waste that these subsystems can't easily be reused outside of the content module.

From what I've seen of the eZ Components they will solve these type of issues. They will form the building blocks on which future versions of eZ publish are built. From what I can tell current version of eZ doesn't utilise components at all, although some of the components features have made their way into the eZ publish libraries. (Of course running under PHP5 allows the use of components in extensions).

New versions

Yesterday I was alerted to an update to the eZ Publish roadmap by a posting from Łukasz (eZ Fourm Guru) Serwatka. (I don't understand why eZ aren't talking about this themselves?)

The roadmap has the next point release, 4.1 (focusing on a new Online editor with support for IE7 for Vista) happening in Q1 2008. Given we are about half way through February that makes it due somewhere in the next month and a half.

Of more interest to me was version 4.5, with the focus points highlighting the integration of a new template & workflow engine based on eZ Components.

With a tentative release date of "Summer 2008" one would speculate that it is planned to be launched at the Summer conference. (Assuming that "Summer 2008" refers to a northern hemisphere summer, because we've in the middle of Summer, here down under. Come on eZ people, you're global!)

I do wonder what "Support for more runtime platforms" refers to?

Better, Faster, Shinyer or a Monster?

In terms of version numbers I'd like to see the version that incorporates eZ Components go up a major revision number and become eZ 5.0. This would signify the gravity of the change. We are not talking about some bug fixes and enhancements here, but replacing major components.

I'd even go so far to suggest that eZ4.0 goes into maintenance mode (feature freeze, whatever you want to call it) and eZ5.0 is written from scratch, built on eZ Components. I fear an eZ Publish that has it's underlying systems replaced bit by bit with eZ Component versions will quickly start to resemble a Frankenstein's monster.

The current system has been through ten major revisions and countless minor ones and is quite stable. I suspect there be teething problems if not major pain (but as the saying goes "no pain no gain") for many with this change. And of course the entire admin and various default user interface will have to be rewritten for to work with the new template syntax.

I suspect that given the current templating system is tied to the caching and translation systems (part of eZ Components 2008.1) that we'll also see those replaced with eZ Components ones as well.

Also of interest was Derick's post earlier this month about the eZ components 2008.1 roadmap. The majority of the listed new component and enhancements appear to have a specific eZ publish focus. These have tentative alpha & beta release dates in May 2008. This would make a tight squeeze if eZ 4.5 (eZ Components) was to utilise this eZ Components release. Does this mean that eZ 4.5 would not have Translation & Character set support?

So what do you think?
Is eZ publish 4.0 like Vista?
Do you want to see an eZ publish that is half components or a ground up rebuild?
Do you care? ;)

[1] Paraphrased from: http://en.wikipedia.org/wiki/Development_of_Windows_Vista

A roadmap for the next eZ Publish releases is now available. eZ Publish 4.1, the next major release, will include the new Online Editor, as was previously mentioned in Community Newsletter #1/2008. The new Online Editor will have various enhancements regarding usability and the user interface, and will support Internet Explorer 7 for Windows Vista. eZ Publish 4.1 is expected to be released in the first quarter of 2008.

Lately we've been having this discussion with André about different suggestions regarding ways to improve eZ content model:
http://ez.no/developer/forum/suggestions/in...

It was started by my own suggestion to introduce an additional flag that would sort of require objects attributes to be present (or, in other words, impossible to remove from the presentation/XHTML layer). And that actually resulted from my early eZ days questions on how does eZ Publish actually deal with missing attributes...

Back to the additional "require attribute flag"

1. "Required" flag, that we have today, suggests by semantics that the attribute is required, however, that is not so. I hope I was the only user not to go in depth with this issue, however I expect otherwise. Today's "required" should in my opinion be called "Value required" or "Require value", because that's what the checked flag actually causes.
2. Why isn't the default behavior of attribute validation such that all attributes are required to be present?
3. Doesn't lack of all/any of the solution ideas mentioned above (or other) make the editing process vulnerable to any manipulation of the presentation layer? Isn't that comparatively easy to simply omit all uncomfortable attributes, for example datatype-based CAPTCHA, limits, identifiers, etc.?
4. "Require all required" as a class attribute/flag actually doesn't make much sense with current "Required" meaning. What would it mean? Require all required values? This is why I suggest that there should be a separation of "required flags". We could leave today's required as "Require value" flag, as I suggested above. Then, there should be an additional flag that would decide whether the attribute itself is required to be present in the editing process. This would be much more flexible than earlier "require all required" and at the same time seems to make that idea useless.

Discovery

Well, I finally found some time to look at it again, especially into the eZ Publish kernel. I followed the path that an attribute takes from the edit view all the way to the datatype itself. Actually, I found out that no matter what you do, no matter how you manipulate the presentation layer, the attributes of a content class always reach input validation function in their datatype. So it is up to the given datatype to take further steps, but it's already a good news: it is possible to force attributes without any kernel/lib modifications! Here's an example (ezstring datatype):

A quick update on my four points above: I still believe the new flag would be a useful solution. I still believe there's space for both "required flags". I'm still not sure why checking an attributes presence is not default behavior in most (or all) out-of-the-box datatypes. But at least now I have it under control! ;)

And here's how the new flag could work:

What do you think?

LA is wearing her typical veil of grey-brown smog. I’ve been here for enough hours that I can’t really smell it anymore – or much of anything else, for that matter. I’m at the LA Airport Weston with the rest of the SCALE 6x attendees.

I’m sitting in Steve Oualline’s session on Linux in Early Education. I know Steve from his excellent Vim cookbook (and other books.)

There 50+ people attending.  Steve Oualline is joined by the cute-as-a-cute-button daughter Grace Oualline, who is four years old.

Point form, here are some messy notes on what Steve covered in the session.

• Link Summary

  • http://www.oualline.com/
  • http://www.oualline.com/vim-cook.html
  Related posts Planning my SCALE 6x Attendance (4) OpenMind 2007: The Novell Keynote (2) Conference Report: OpenMind & MindTrek 2007 (5) OSCON Lowlights: greenplum Keynote (12) OSCON Highlight: Making Sales While Making Friends (0)

If you read my post on getting the most out of conference attendance, you know that I’m trying to reduce the environmental costs associated with my conference attendance. I even made a plan. As with most plans, real life is a bit different. Here’s how I’ve done: Taxi from home to YVR (I would have taken [...]

Welcome! This past week saw the release of SHARE! Magazine, a new monthly community newsletter that features interviews, stories, reviews, and more about the eZ Ecosystem. Other interesting news this week includes the release of a new article on ez.no about using SVN in eZ Publish projects, a roadmap for eZ Components 2008.1, and an improvement to the login process for eZ Projects. Happy reading!

The first beta version of the eZ XML Installer has just been released.

Please see here for details.

Please go here to download and test this version.

eZ My Collected Info extension gives front-end access to one's collected info. The ownership of the collections is determined based on the ownership of the content object that collected the information. In other words, it is not who sent the information, but whose object it was sent to, that is considered the owner, and thus can browse/read, and optionally delete.

The extension makes it possible to browse though the collections by class and then by object (a tree-like menu is provided for easy access). A detailed class-level configuration is possible to allow/disallow collection deletion, custom identifiers, and custom/default templates.

The extension comes with two module views and two access functions for a flexible management. The standard browsing view can be accessed through: /index.php/siteaccess/mycollectedinfo/browse

Read the settings/mycollectedinfo.ini file's comments for more information.

You can download the extension from: http://ez.no/developer/contribs/hacks/ez_my_collected_info

After our release just before Christmas we've been working towards a roadmap for the new 2008.1 release. In the new release we will be addressing some importing parts of Web applications: RSS/Atom feeds, Document conversion, Search and Translations. The full roadmap can be found on the eZ Components website page.

There are many other things that we're interested at in having as part of the eZ Components, but at the moment don't have the time for to implement. If you are interested in contributing, have a look at the issues that we've marked open for contributions in our issue tracker. If you're interested, let us know through our mailing list.