Propel

Pros – First, let’s be clear I’m not talking about the pros of using an ORM. I’m talking about the good things that this ORM implementation brings to the table. Those are:

• Hydration Speed – You can argue you should never retrieve hydrated PHP objects from query if you don’t plan on taking some sort of save or delete action on it. Yes, that’s true from a performance standpoint, however, if you are building a site where performance simply isn’t a concern then you’ll be pleased to know Propel can hydrate a set of objects quickly enough to be used in building a view (i.e. a data grid of some sort).
• Classic Getters/Setters – You get these methods stubbed out in the base classes that Propel generates and you can override them easily. I should note Doctrine can do similar sorts of things but not in a conventional way.
• Support – The Propel mailing lists and IRC channel on freenode are pretty active, thought, not near as active as Doctrine’s.

Cons

• Dependency hell – Propel has improved this but it’s still not perfect. Back in the early days, before PDO, you needed Propel’s generator, Phing and Creole. Now you just need the generator and Phing. Phing is very much like Java’s Ant build tool. While I understand and get why they use Phing, it adds a layer of complexity that makes it a barrier to new users. Propel’s generator isn’t as bad as it is just a set of Phing targets to do Propel’s bidding. If you come from .NET or Java using Phing won’t be a big deal but if you aren’t familiar with Ant or nAnt then Phing will come with a learning curve.
• Criteria – Propel’s way to help ensure portable queries are built is via their Criteria object. While I get the need for it, not having a explicit way to run native SQL short of getting a PDO connection and doing all the work that way is a short coming. In fact, I despise Criteria so much I never use it, mainly because it doesn’t take too much work to hit a situation that Criteria either can’t handle well or make the code so complicated it’s not worth it.
• No 5.3 namespace support – Let’s face it, we are all tired of Really_Long_Class_Names ala PEAR, Zend Framework, et. al.
• Community – This is probably hard to blame on any one person but for a long time no work was done on Propel. There was a change in project leads which took a long time and the development efforts took a while to get going. I’m happy to say the team is active again, but a lot of ground was lost during the downtime.

Doctrine

Pros

• No other dependencies. Doing builds is easy as creating a simple PHP command line file and running it. No Phing, no other external property files.
• Magic finders – I love this. Say you have a user table with a user_name field that has a unique index on it. Retrieving this is as simple as

  Doctrine::getTable('User')->findOneByUserName('janedoe');

  . Propel would require a few more lines setting up a Criteria object and running it.

• Named Queries – This is something I pitched to the Propel development team quite a long time ago that always got a luke warm reception from the community. I ended up implementing my own named query implementation which worked well enough that I never used Criteria. With Doctrine you just get it out of the box:

  $this->addNamedQuery(
      'someQueryName',
      \Doctrine_Query::create()
          ->select('*')
          ->from('User u')
          ->where(user_name = ? AND 'password = ?')
  );
  

  Now I’m not totally in love with that syntax, it’s not much better than Criteria, honestly, however I go through that pain once and then I can just say:

  $user = \Doctrine::getTable('User')->find('someQueryName', array('janedoe',SHA1($password)));
  

  It’s also worth noting you can also use named queries to issue raw SQL, though, it will only return the raw recordset. Some of you are probably asking WTF? Named Queries? Read up on them, decide for yourself if they are for you…all I can say is after having used an implementation for years I’m sold on it (maybe that can be a future blog post).

• Documentation – Their documentation is top-notch. Only improvement that is needed is comment support to the manuals.
• Community – Let’s face it. Doctrine has gained some traction and all you need to do is follow the mailing lists, IRC and other community resources to see they simply get it. Their partnership with Zend Framework is a shining example of good strides in this area.

Cons

• Hydration Override – This one had me scratching my head the first time I noticed it. By default, if you fetch an object by the same primary key twice you don’t get two different copies, you get a pointer to the most recent version. On the surface that makes sense but there are a number of reasons I don’t like this as the default setting. Luckily you can turn this off through a configuration setting when you initialize Doctrine.
• Hydration Speed – This is my biggest complaints with Doctrine. If you run a query that pulls a parent/child relationship (i.e. a customer and their orders) this take a lot of time with Doctrine’s hydration method. The complexity is the circular references you can get. I don’t know why Propel handles this so much better but the impact is you can’t use Doctrine’s hydrated objects in you views. The way around this, I’ll call the Doctrine Way, is to have them hydrated as arrays. You still get the parent’s children, you just aren’t working with a native PHP object. When you think about it, it make sense, though I still prefer having a choice. The performance hit you take, even on simple queries, makes the array hydration mandatory if you are pulling more than one or two records from the database.
• No 5.3 namespace support – It too doesn’t support namespaces yet.

This isn’t meant to be a comprehensive review of either system, rather, a punchlist of noteable things. I don’t feel this blog post is near comprehensive enough to base your decision on, rather, it can be used in addition to your findings. I’d love to hear the other pros and cons from either camps.

I owe quite a bit to Geeklog…after installing Linux and PHP for the first time over 12 years ago I ran across Geeklog, learned a thing or two about open source development and started Iowa Outdoors (which I’ve since sold). Not long after that I was fortunate enough to serve as the project lead for Geeklog before handing it off to the current lead, Dirk Haun. Back then, there weren’t many viable options in the now overcrowded PHP CMS market. Sadly, I’ve watched Geeklog’s popularity slowly decline to its current state. That said, I have a few constructive things to say to the Geeklog community and the PHP community at large.

First to the Geeklog community. You’ve run into rough times. WordPress, Joomla, Drupal and company really are the champions in this space. Without doing more digging than I care to, I know Geeklog is far behind in any of the hard metrics that really matter (code commits, # of active developers, etc). Just a hint of proof is had by comparing Geeklog’s Ohloh stats with this, this and this. Then there those things you can’t quite quantify, the passion of the community and the level of innovation happening. Right now I feel the Geeklog community is pretty stagnant. Some of this is likely to be blamed on the fork of Geeklog (whose Ohloh stats don’t speak well either). Fact is if you combine both glFusion and Geeklog’s numbers together it still paints a pretty bad picture. You could argue they don’t need to aspire to be like WordPress, Joomla and Drupal which is fine but what I think has gotten lost in all of this nobody has consciously said if that’s the game they want to play and, if not, what differentiates Geeklog from the rest? In the meantime, the set of features added over the past year or two suggest, in fact, they are playing catch-up to some of the features found in those other systems. That’s not bad, but my point is Geeklog seems to lack a tangible goal. I guess that is part of the nature of open source…the perpetual, organic, itching of scratches but I still feel open source projects need to have long term visions far beyond the next commit, next point release and even next major release. With that said here’s some suggestions for Geeklog’s community in no particular order:

• Change your name – I attempted to address this with AptitudeCMS and failed but something has to be done. I’m not sure if there is a precedent for a name change in a well established open source project but it has to happen for Geeklog. To me it is branding 101. For anybody outside of a blogger or hobbyist, it’s hard to take the Geeklog brand seriously. Pointy haired managers scoff at such a name (I’ve seen it). Sure you risk confusing or alienating people but I feel Geeklog, as a brand, is hard to sell. That said, even without a name change the remaining points are crucial.
• Change your image – The Geeklog homepage screams mid-1990’s era design. It’s the first impression we give users. Even if you don’t want to compete directly with the bigger kids on the block, you can’t argue that Joomla, WordPress and even the Geeklog fork looks better. It’s the first impression a user gets. I think improving the Geeklog homepage will lead to more interest. Once captivated, I have now doubt the codebase speaks for itself but, for now, the Geeklog homepage is forgettable for new users.
• Get social – Geeklog is no where to be found on Twitter, Facebook, etc. The missed opportunities here are, frankly, staggering. The PHP community (as well as Drupal, Joomla, etc) all have a strong presence in these areas and I have no doubt the Geeklog community could benefit by joining the conversation.
• Blog – Let’s face it, there isn’t much in the way of active Geeklog developers. The ones there really need to blog about what’s going on behind the scenes. What are you working on? What’s a challenge you are facing? Any good commits lately? This in part gets back to the goal setting discussion but it is more todo with giving the community a glimpse of what is going on.
• Find a partner – Ok, this is probably one of the more controversial points and one that is often dodged in open source discussions but behind nearly all successful open source projects is an organization. Sometimes it is not-for-profits but many times it is a private company or two. Right now there isn’t a single Geeklog developer paid to work full time or even half-time on the core of the system. Geeklog’s current codebase, in my opinion, has to be worth that investment. I think part of the problem here has to do with the name, image and branding issues I brought up. That said, I know of a lot of organizations making selfish use of Geeklog without giving anything back. No bugs, no code, no testing, no translations nada. Zilch. Now before the hardcore OSS supporters flame me, I’m not suggesting the project be effectively run by a company or an organization, rather, there should be enough of a community still where they can contribute developer hours to the project. I believe strongly the project itself needs to remain organic able to change with the needs of those who lead…but that some investment by industry is needed. Who will stand up?

Now to the PHP community at large. As I look at AptitudeCMS, I see a body of work that started before there were any other PHP frameworks around. I started with an MVC implementation. I incorporated a simple template engine. Later added an ORM. Much of this happened over many employers and well before anybody uttered Zend Framework for the first time. AptitudeCMS as a project is a failure in large part because it was never really released as a “formal” project until well after current PHP framework space became cluttered. Fine, it is what it is. However, to see this stuff rot and be used only when I have a new project come up seems silly. I’m pleading, for my own sanity, don’t let this code go to waste. Feel free to dissect it, borrow anything you find useful and laugh at any bad code you dig up. Some areas of focus:

• MVCnPHP – It’s a viable alternative to Zend Framework’s MVC implementation. It’s small, configureless and doesn’t present file contention issues common with ZF controllers. I’m sure a Zender can point out ways around this but most ZF projects I’ve seen have all the logic in the controller which seems really wrong to me and is a bit painful when you have multiple developers working in the same controller. Sure SVN, etc can handle the merge but you end up with a lot of merges. MVCnPHP is much more atomic, view logic goes in a simple, small view class. Command logic goes in a similar command class. The controller is only responsible for routing requests between views and commands. An upside to this is MVCnPHP also has basic support for tainted variables. For the unaware, it’s a simple feature that notifies developers with exceptions when an unsanitized GET or POST variable is used.
• Filtering – I built a filter class on top of Zend Framework that can easily be added to MVCnPHP views and commands. Without much work it could also be incorporated into Zend Framework MVC implementations. Look first here then see the “cool code” in the Filter class which is nothing more than a class that passes calls thru to Zend’s library and then the abstract view that uses it. I doubt the code will tickle you as is but I think conceptually it has merit for someone out there.
• ORM->Form and Form->ORM – Because we use Propel we were able to dream up a way where we could hand a view an object and have it pre-fill from that object without us having to explicitly set the form field values. Similarly, in our commands we found a handy way of creating the same ORM objects from the submitted form without having to explicitly map and set the ORM object’s values. This was a huge time saver. I think with a little work this code could be modified for Doctrine. Here’s how we map a form submission to a set of object(s) and here is mapping a object to the form

One thing I want to warn the community at large about is I’m seeing what feels to me like a trend in PHP to conform. You could argue that this very blog post is me, in a way admitting defeat and conforming, but I want to state the obvious that you always have a choice. It seems like many people are choosing to use part of a framework they have already installed instead of challenging whether or not it is the best tool for the job. Just because a filter class is included in Zend Framework doesn’t mean you have to use it. Just because ezComponents has a workflow component doesn’t mean you must employ it. Fact is AptitudeCMS includes Zend Framework, has some PEAR libraries and even some things like MVCnPHP. You can argue bloat, file sizes, which is valid but I’m confident you can still cherry pick the best parts of a framework to give you something you can work with long term. I’ve used Flexy instead of Smarty, MVCnPHP instead of Zend Framework and Propel instead of Doctrine. Some could see those as one bad decision after another but it’s simply the result of a cherry picking exercise I did long ago. Today I’d likely make different decisions but I can tell you I wouldn’t put all my eggs in one basket. Nor should you.

This blog entry, a self admission to failure, hopefully didn’t upset anybody along the way. To be clear I’m the only one who failed here. Maybe “fail” is too harsh a word as I’m quite happy to make this transition but I want to be clear to Dirk Haun, the Geeklog Project and those of you whom I’ve brushed IDE’s with are all people I very much respect. I hate “losing” and this feels like a loss and will always feel that way. If anybody makes use of any of these suggestions please pass that along in an email to me. It will take a bit of the sting off.