The odd bit

Once is an accident, twice is a coincidence, three times is an enemy action.

The odd bit - Once is an accident, twice is a coincidence, three times is an enemy action.

Enhanced Selection Datatype v2.0

I have some good news for the fans of the Enhanced Selection datatype for eZ publish: version 2.0 is in the works. The new version will contain some shiny new features, but it will also be completely rewritten from scratch. The code of the currently released version is almost ancient and a rewrite will make it easier to add new features (and of course, bring it more up to date with eZ standards).

It’s possible that class content and/or object content won’t be compatible between the two versions, but in that case I will make an upgrade script to ease the transition. I do aim for the fact that current object-level templates won’t need to be changed for the new version.

Another issue is eZ publish version compatibility. The latest stable release is 3.9.x and both the 3.6 and 3.7 series have had their end-of-life bugfix release which means they’re unsupported as of now. My plan is to support version 3.8 and newer. My guess is that this is not such a big problem for 3.7 users (the new version will most likely be compatible, just not supported). The real problem will most likely be 3.6 and older releases, mainly due to the fact that they’re based on PHP 4.3. If I go for 3.8+, I cannot guarantee it’ll be compatible with the PHP 4.3 series. And that’s the reason for this post – and I’ll only say it once:

If you want 3.6 support, speak now or remain silent forever. Now where did I hear that before? 😉

Object/Relational Data Persistence in PHP

Another post about PHP and the topic is once again data persistence. I’m starting to wonder if this is my search for the Holy Grail…

I previously blogged about some differences in the implementations of the Zend Framework and the eZ components. Let it be clear, the Zend Framework’s implementation is also not the most logical one.

Something they have in common is that neither can cope with composite keys. No biggie you’d think until you encounter two entities with a many-to-many relationship. While there are ways to circumvent that problem, I’d rather have it working without trickery.

The real oddity in the Zend Framework comes when you start working with results from database fetches. The persistence starts by defining a PHP class that extends Zend_Db_Table. A fetch from that table results in an object of the Zend_Db_Table_Rowset class. Iterating over that object results in objects of the Zend_Db_Table_Row class. This means that one row from the database is not an instance of the persistent class. The real drawback of that implementation comes when you want to define custom properties on “persistent objects”.

An example of such a custom property: artists and songs. Each artist is an object of the Artist class. Instead of having to load the Song table yourself and query it for all songs of Artist A, it would be a lot handier if you could access all songs by using a property, e.g. $artist->songs.

If you would like to achieve such a thing with the Zend Framework, you have to start implementing your own extended Zend_Db_Table_Row classes and making sure all results are casted to the new type. Not good. Another possibility would be to implement something in the persistent class (the table’s class), but that’s even less logical.

So here I am… once again in search of a good implementation. Looking back at things, the data persistence implementation that ships with eZ publish is not that bad after all. Anyways, I hereby call upon the world to leave a comment if you know of any other data persistence implementations for PHP5.

P.S.: I’ve tried looking at Symfony, but I found its installation to be too cumbersome at the time (not to mention that I couldn’t download a required library). So there’s no need to mention that one.

Zend Framework (PHP)

I’m currently working on a website for myself using the Zend Framework. Actually, it’s take #3 of the project. The first attempt never had a chance of succeeding even remotely. The second attempt was much better, but the pieces of the puzzle didn’t really fit together.

The biggest problem I experienced while working on the second attempt was the data persistence implementation of the eZ components. It’s really not convenient to work with: you must implement at least two functions (even though the API doesn’t force you to implement them) to manually return the data that should go into the database and to set object properties to values from the database. You also need to create a definition file that maps properties to database fields. Hey, if there’s a mapping, why do I still need to implement manual getting/setting in the class? Another major shortcoming is that a table’s primary key must be an auto-increment integer.
Data persistence is a lot easier in the Zend Framework. All you need to do with your class is extend the Zend_Db_Table class, follow a couple of naming conventions and it works! If you really want to be a difficult guy, you can override the naming conventions.

That’s the biggest difference I’ve encountered so far. There will probably be follow-ups to this post as I continue to dig deeper in the Zend Framework.

Regular expression datatype v2.3

Just a quick note to mention that a new version of my regular expression datatype has been uploaded to its contribution page. Version 2.3 “fixes” the issue I mentioned in my previous post on the subject. Two additional things have also been changed, namely:

  • Changed: Shortened object-level error messages
  • Fixed: Undefined variable used in helper function

It’s also available in the community SVN repository for those who always want the latest version.

Regular Expression Datatype: Planned Update

A recent comment to my regexp datatype contribution reminded me of an irritating shortcoming in eZ publish. It’s not possible for datatypes to send error messages back into the class edit. It’s only implemented on the object level for some bizarre and obscure reason.

I plan to incorporate class-level error messages in the next release of the datatype (expect the release soonish) but it’s a real shame that this shortcoming has survived 8 releases so far.

But for now, back to C# 😉

Regular expression datatype v2.2

When you start creating a piece of software you always think you’ve got all possible features covered. As soon as all those ideas are actually implemented it’s time to call it version 1.0. But then you start using that piece of software and the new ideas just keep coming.

My regular expression datatype for eZ publish isn’t any different. A couple of new features and a bugfix warrant a point release bringing it up to version 2.2. Here’s a brief overview of the changes:

  • Fixed: Regular expressions are added to/removed from the first class attribute using this datatype (Thanks to Richard Tuin for reporting this issue)
  • Added stripping of tags with possibility to disable the stripping via the ini file
  • Added possibility to control the size of both a text line and a text area in content/edit

All details are on its contribution page.

Regular expression datatype v2.1

I’ve just updated my regular expression datatype, regexpline, to version 2.1. The latest version of this eZ publish extension brings you these changes:

  • Enhanced contentclass view template
  • Fixed naming pattern if no subpatterns have been defined
  • Fixed display of object content when using it as a line field
  • Possible fix for excessive whitespace when using text block mode
  • Removed debug
  • Added possibility to “negate” regular expressions/presets. (must *not* match this regexp instead of must match)
  • Implemented hasObjectAttributeContent() (has_content in templates)

As usual, you can find a download on its contribution page.

Regular expression datatype updated

In the past few days I’ve released two new versions of my regular expression datatype for eZ publish, regexpline. Version 1.1 contains these changes:

  • Fixed: CS issues
  • Fixed: Only use internal function to fetch the regular expression
  • Fixed: Naming pattern (title function) does not return an empty string when given no input or invalid input
  • Added: Custom name pattern similar to the object name pattern of a contentclass

And version 2.0 has been published today. Here’s what’s new in this version:

  • Added: Multiple regular expressions can be entered
  • Added: Multiple presets can be active
  • Added: Custom error messages per regular expression/preset
  • Added: Display as text line or textarea (in object edit)

More info and download locations can be found on its contribution page.

The lurking dangers of references in PHP

A while ago, PHP 4.4 was released to address a rather weird memory corruption problem in the PHP 4.3 series. The problem was related to returning by reference. The bug allowed statements to be returned by reference while it should only be possible to return variables by reference.

To provide users with a PHP 4.4 compatible version of eZ publish, eZ systems released version 3.7 which is a clone of version 3.6 with the reference fixes added to it. Simply changing the 3.6 codebase was not an option because what was needed in 3.6 to go around the memory corruption would no longer be valid in PHP 4.4. The reverse was also true, what was needed in the PHP 4.4 version would trigger the memory corruption in 3.6.

Unfortunately, the problem doesn’t stop there. There are also a lot of extensions for eZ publish. Some of them don’t need a change while others need to be updated to be PHP 4.4 compatible. I’ll give an example…

If you happen to use e.g. the eZXML library in your extension, you’re among the lucky ones who need to change some code for the newer version ;-). A great example is eZDOMDocument::createElementNode(). That function returns by reference in eZ publish versions prior to version 3.6 and returns by value from 3.7 onwards. This means your code for 3.6 should look like ($doc is an instance of the eZDOMDocument class) (code A):

$exampleNode =& $doc->createElementNode( ‘example’ );

And for 3.7 (code B):

$exampleNode = $doc->createElementNode( ‘example’ );

The difference is pretty small if you look at it, but it could be rather significant. If you use code A for both versions (3.6 and 3.7) it should not be that significant. It’s how it should be for 3.6, while the reference assignment should be ignored in 3.7 because the function returns by value. However, you’re not following the eZXML API which could have an unknown impact now or in later PHP versions and it’s not a good coding practice.
One could also suggest to use code B for both versions, but then things get worse. You’re alright in version 3.7 (or any PHP 4.4 version for that matter), but you’re simply ignoring the return by reference in 3.6 which means you’re back at the initial problem: possible memory corruption. And just to be sure, I asked Derick Rethans (PHP and eZ publish developer) if ignoring a return by reference would be a good idea in PHP 4.3. His response:

It’s indeed how it not should be done. Returning by reference from a function, while not assigning the result by reference will not work (ofcourse, as the reference is ignore). As far as I can remember it is exactly this case that caused the memory corruptions in PHP 4.3.x.

So be careful when switching to the new code because you can’t predict when the memory corruption bug will appear, but count yourself lucky if you don’t encounter it. I have encountered the bug before and it absolutely makes no sense when you spot the problem.

Note: 3.6 in this post refers to eZ publish version 3.6 which in turn refers to the eZ publish codebase for PHP 4.3. 3.7 in the post refers to eZ publish version 3.7 which should be read as the eZ publish codebase for PHP 4.4.