I had been waiting for PHP 5.3 for a long time, and looking at the progress for Zend Framework 2.0, I got very frustrated. But it made me keep a closer eye on the ZF Wiki, and when I encountered a proposal for Zend_Db_Mapper, I recognized many of the PoEAA patterns I had abandoned for reasons of practicality, but longed for so much. But the work was far from done, so I emailed the proposer, Benjamin Eberlei, on 19 December last year, offering my assistance. He responded..

Hello John,

I stopped to work on Zend Entity (and Db Mapper) when we realized that

it actually would end up being sort of a clone of the Doctrine 2 project,

so we joined forces and we will see some pretty neat ZF and Doctrine 1 /2

integration very soon.

you are always welcome to contribute to doctrine 2, its quite advanced

already.

greetings,

Benjamin

I was very disappointed. Zend Framework has a certain robustness, a defensiveness, that I've come to expect (although around this same time ZF started to disappoint in this regard). Doctrine, to me, was superior in functionality to Zend_Db_Table, but it definitely lacked defensiveness. It was messy. And "you can't build a palace on a pile of shit", the lesson I extracted from my experience with the SilverStripe CMS.

I responded to Benjamin expressing my disappointment and lack of faith in the quality of Doctrine. And even though he responded with assurances that Doctrine 2 was very different from Doctrine 1, I remained skeptical and disappointed.

Some months passed, and eventually I did have another look at D2, which had reached the last Alpha stage. I didn't really look at the docs, I assumed that it would be better than D1, but remained skeptical. Regardless, a bleak hope of "a better Doctrine" started to glimmer, and I started to investigate. I quickly came across this presentation by Jonathan Wage. He had me at "completely rewritten", but going on to "kill the magic", it really caught my attention. The "magic" had annoyed me greatly, as it is very inflexible, a source of unclear execution flow, and perhaps the primary source of the lack of defensiveness in D1. Going on to replace the magic with proper OO principles, I was sold. This Doctrine was indeed better, fundamentally better. There was more to the presentation, but it was just icing on the cake. The realization that it was still in alpha, tempered my enthusiasm enough to let it be.

Then I came across a project, that had the need for composite objects in a hierarchal structure, that needed to be persistent. Given the possible nesting level of these structures, I needed something that doesn't require many round trips to the database. Enter Nested Set (aka "Modified Preorder Tree Traversal"). Doctrine 1 does support that, but as it turned out, the combination of inheritance using "column aggregation" and nested set, was asking too much. This was mostly due to the poor inheritance mapping in D1. In desperation (and remembering a promise of "better support for inheritance"), I looked at the latest release of Doctrine, which turned out to be 2.0 BETA1. I was pleased the project had finally reached beta status, and started looking at the docs. I became more and more convinced that it was doable to rip out the guts of the application and replace it with D2.

This was a daunting task though, and I did underestimate it. I ended up namespacing the whole application, creating my own Nested Set implementation for use with D2, and overall just making mayor changes to the application. It put mayor stress on the deadline and myself, especially halfway through. But, the end result seemed worth it, and I am truly impressed with Doctrine 2.

Another thing I am anticipation of is Symfony 2. I never cared much for S1, but I had a look at S2 and it looks pretty good. It relies pretty heavily on DI, another prerequisite for effective Domain Driven Development. Regrettably it won't reach beta until next year. Fabien Potencier apparently coined the expression "kill the magic", and seems as impressed with D2 as I am:

And man, Doctrine 2.0 is gorgeous. Doctrine 2.0 is one of best things that's happened to PHP in a long time.

When PHP 5.3 came out, I was ecstatic. Namespaces, finally! Actually some parts of the implementation were a bit disappointing, but we'll leave that for another time. In that same enthousiasm, I jumped on closures like a hungry dog on a steak. Only to find the steak to be an old shoe.

Of all the well known design patterns related to ORM, the Proxy pattern (or more specifically, Virtual Proxy) is perhaps the most under-appreciated (with Unit of Work Controller and Value List Handler coming in second). This may be because it's not strictly a data source pattern, and you won't find in PoEAA chapter or Core J2EE Patterns. It is actually in the GoF, which doesn't contain any data source patterns. For me personally, Virtual Proxy will always be directly associated with data loading, as that is what I first used it for in 2006, although since then I have used for other occasions where object initialization was abnormally expensive. It is a pretty versatile pattern.

In a nutshell, a Virtual Proxy is a "lazy loading" pattern that defers initialization of an object until it needed. The proxy does not contain the actual resource, but "knows how to get it". It does this by extending a subjects class while delegating to an instance of that same class, the subject. Basically this is what a Decorator does. But instead of overriding methods to add behaviour to a decorated object, it overrides them to trigger initialization of the subject (loading from the database in the case of an ORM), before delegating to the subject. Like with a decorator you'll have to override every method so that it is delegated to the subject. This makes manually writing proxies a pain.

Yet again.

Actually, using bits and pieces from previous works of art and a lot of red bars that turned green eventually, it is actually already a usable framework. Which allows me to focus on the more interesting stuff that are going to set this framework apart. Starting with the data layer.

(This gem was taken from SilverStripe)

At SilverStripe, they've gone through great lengths to rape the OO model (seriously, stay clear). But according to SS, their way is the right way, and PHP has it ALL WRONG. The fact that SilverStripe's codebase looks like my kitchen when the gf is out of town, is as defensive as an 80 year old Amish women in a coma, and about as structurally sound as house of cards, is ALL PHP's fault! Obviously is has nothing to with the way they are trying to use static properties. Right.

/**
* ...
*
* Note: please ensure that the static variable that you are overloading is explicitly defined on the class that
* you are extending.  For example, we have added static $has_one = array() to the Member definition,
* so that we can add has_one relationships to Member with decorators.
*
* If you forget to do this, db/build won't create the new relation.
* Don't blame us, blame PHP!
*/
 

Adding a winky does not make it funny or right, sorry. Actually, double fail for smilies in code. Triple fail for writing the biggest piece of crap in PHP history (and that's saying a lot, MediaWiki anyone?)

I sometimes get the feeling that some PHP developers think SOAP is hard to use. When in most cases, nothing could be further from the truth.

As a follow up on my previous post, I decided it would be interesting to see what effect using the php://memory wrapper or APC would have on the results.

Cutting straight to chase, the results:

r448191@goliath:~/bench$ php bench.php 10

Total include: 0.000389575958252

Total unserialize: 0.000274181365967

r448191@goliath:~/bench$ php bench.php 100

Total include: 0.0033860206604

Total unserialize: 0.00247645378113

r448191@goliath:~/bench$ php bench.php 1000

Total include: 0.0342044830322

Total unserialize: 0.0263719558716

r448191@goliath:~/bench$ php bench.php 10000

Total include: 0.32866358757

Total unserialize: 0.25150680542

r448191@goliath:~/bench$ php bench.php 100000

Total include: 3.23683238029

Total unserialize: 2.56990027428

Zend Framework is now at version 1.7, adding better internationalization support, and supporting the Dijit Editor Widget. Ok, better internationalization support can only be good (since it was already more than decent), but the Editor Dijit should have been in 1.6. I gave the Dojo support in 1.6 a test drive when it was first released, only to find that it was mostly useless. Hopefully that has changed, I haven't tried it yet.

Putting it off for forever, I have finally started writing about Design Patterns on the PHPFreaks.com site. Originally, I was planing on creating a single tutorial on all common patterns. The magnitude of task is why I kept putting it off.

Instead, I am now covering one or two patterns at the time, making for byte sized chucks for reader and writer.

I implemented Transform View (XSLT) for Zend Framework. It's a relatively basic class that allows layout templates and calling Zend Framework View Helpers from XSL templates. Read on to view the class and some basic explanation.

On my blog I assume the reader to be eloquent in OO PHP. Knowing very well this isn't the case for 70%+ of the PHP developers out there, I've started a series of tutorials on PHPFreaks.com that will give you the grand tour of OO in PHP.

Part 1 is an overview of what features PHP has to offer in respect to OOP.

http://www.phpfreaks.com/tutorial/oo-php-part-1-oop-in-full-effect

Part 2 is an introduction to some OO principles and practices.

http://www.phpfreaks.com/tutorial/oo-php-part-2-boring-oo-principles

Part 3 is an introduction to UML Class Diagrams and class relations

http://www.phpfreaks.com/tutorial/oo-php-part-3-uml-classes-and-relations

More parts to come.

My idea of fun is to combine existing patterns, producing a solution to more specialized problem than the original pattern specifications individually. I should probably get out more.

In this case, I was faced with the following problem: how to create a flexible, complex and multi-dimensional chain of Command Objects (a chain of commands and subcommands), that was executable top down over and over, without re-executing the same command twice for that chain. Operations should block the execution of their children on failure to complete. Children should be executed serial, and isolated from each others potential failure.

When faced with creating complex relations between objects of the same type, with operations to be executed on the underlying structure transparently, the Composite pattern can usually save the day. I created a mechanism to create a composite structure of any implementation of an abstract Command Object class.

Because I implemented Composite, I already had a mechanism to execute a Command and it's descendants in the order required.

Whether you're running your application as daemon or your using a caching server, homebrew (in that case you probably want to use the shmop extension, which will save you the trouble of creating a PHP script daemon) or third party such as Memcached, there is a limit to the amount of memory you can use.

You may want to cache some items practically indefinitely, like keeping a visitor's session for 6 months. Keeping the session in memory for that time is of course ludicrous. Also, should your daemon handling caching crash, or need a reboot, bye bye data. The solution to this is to implement multilevel caching strategy.

Take a look at the following sequence diagram, which illustrates getting an (old) item from cache.

If you know your Design Patterns, you'll recognize a tiny Chain of Responsibility pattern in this example. In essence, we compose a chain of two objects, breaking on the first object that can handle the request. If you look near the bottom of the diagram, you'll notice that after retrieving an item, it is moved to the top of the chain. This done under the assumption that the item will be used more often in this time frame. The item is placed at the top of the stack of the first cache, and will continue to placed there by the top level cache, each time it gets accessed. The stack has a fixed length, so adding new items to it will pop off the least frequently used. The handler will then put it in the next cache in the chain. This is a crude implementation of the LFU (Least Frequently Used) strategy, which doesn't work.

Hold on, did he say "which doesn't work"? Yes, I did. The problem with this approach is that once the top level is full, every new addition to it will cause both a get and a put operation. With a three level (or more) cache, you risk cascading put operations. There is no solution to this in a single-threaded environment (that I can think of), other than being lenient with the amount of space the top level cache can use, and let garbage collection 'enforce' the limit. That means we no longer have a hard limit, but it also means our caching mechanism is as fast as it possibly can be. It's still risky, especially running an application daemon. The following implementation should be regarded as 'food for thought', nothing more, nothing less.