The odd bit

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

Tag Archives: Programming

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.

Firebug

A new star in the Firefox 1.5 universe is born: Firebug. The author, Joe Hewitt, describes it as “a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter“.

Using a simple Javascript function, you can dump whatever you want in its console. It’ll warn you about Javascript errors, CSS errors,… And if you spot an error, just click on the line number given and you’ll jump straight to that specific line in the source. Another plus: the console is per webpage unlike the standard JS console.

The list of features goes on and on so I suggest you check it out yourself. However, I’d like to mention one more nifty tool: XmlHttpRequest spy. Firebug can be used to monitor requests made with an XmlHttpRequest object (read: debug AJAX calls).

Happy debugging! :-)