Home » Posts tagged "Zend Framework"

Propel ORM for PHP

For the last couple of weeks I’ve have been working with Propel ORM for PHP and have really enjoyed using it. Coming from Perl I’m spoiled because it has DBIx::Class which is my ORM by choice and makes fetching data from your SQL database including relational data a breeze. Propel does a really nice job with this as well and though the API differs greatly from that of DBIx::Class I found it easy enough to pick up.

Propel nicely integrates with Symfony 2 and I’m happy with my decision to go with Propel. The alternative would’ve been Doctrine but decided against using it, mainly because of having to learn DQL (Doctrine Query Language). DQL is similar to SQL, but I liked the named methods of Propel better (e.g. filterByCampaign($object) or filterByCampaignId($id)) and in the end with Doctrine you’re still busy writing a dialect of SQL. With Propel and DBIx::Class you can still use SQL when needed (and to be honest I still find it to be a bit awkward at times in DBIx::Class but I understand why it is the way it is). I could also have looked at Zend_Db_Table from Zend Framework which I’ve used in the past but found too limiting.

All in all Propel a nice ORM library for PHP. Be sure to check it out if you haven’t already.

 

Choosing Zend Framework was a mistake

About 2,5 years ago at work we were still using PHP for new applications. With PHP being the language of choice I was looking at what MVC frameworks were available. At the time only Zend Framework (which was at version 1.5) seemed to be the only PHP5 framework. Aside from that it was a mature project and being developed by Zend made me decide to use it. I also reviewed the feature set at the time, of course.

Zend Framework has a steep learning curve but in my experience most OOP based MVC frameworks do. If I remember correctly I first used Zend Framework for an admin panel for a website. Aside from the time to learn the framework it sped up development. At the end I had created a nifty little admin panel for managing company profiles. Administrators were able to manage all accounts (information, pictures) and set-up permissions. A company could in turn manage its own details and pictures.

Programming with PHP became a bit more fun again. Zend Framework provided a mostly consistent API and came with pretty good documentation, although some parts lacked and still do at times.

Being convinced by Zend Framework I started working on the rewrite of a big internal application. This application was written in old procedural PHP4 code. That in itself can work, but only if there’s a decent structure. Which is what this application was missing. Basically it was plain old spaghetti code. Views and logic weren’t separated. HTML, styles, Javascript and PHP were tightly intermingled making it a pain to extend and maintain. The database scheme was a nightmare as well, but with it being a rewrite I could nicely convert it to something more sane and get it normalized. I used Perl and DBIx::Class for this by the way. I should have sticked with it…

It took about 4 or 5 months or so to fully rewrite the application. It probably could’ve been done in 3 months but as I said I found the learning curve for Zend Framework steep. I’ve even reported some bugs I found! Anyway, after several meetings with my colleagues we re-factored a lot of the application to get rid of old nasty hacks and incorrect work procedures of the old application. With the application being written in Zend Framework much of this was easy and fast to realize. Now, 2 years later we’ve added a lot more functionality. The application is still easy to maintain and to extend. And more and more plans are in the making for added functionality.

So, why is it that I think choosing Zend Framework was a mistake? Of course, it’s PHP but as I posted in earlier rants is that only recently I got the green light to use Perl instead of PHP. One problem comes from PHP though. With their latest release in the 5.2 series they suddenly announced end-of-life of PHP 5.2. Long before that it was announced that Zend Framework 2.0 would use PHP 5.3 exclusively. I knew that. But with instantly declaring PHP 5.2 dead and deprecated supporting Zend Framework 1.x after releasing 2.0 doesn’t seem to be required anymore… Why? Because after they’ll release Zend Framework 1.11 they stop doing major releases of the 1.x series. Even if I would be able to use PHP 5.3 it would be a lot of work to refactor the code to be compatible with 2.0.

Now this doesn’t directly imply that Zend Framework 1.11 will stop receiving updates in the form of minor releases. But looking at its history I fear the worst. At one point it was said that the current and the last 2 major versions would receive security updates. Out of 2 times this happened once. The second time it was supposed to happen only the current and last version were updated (I believe this was version 1.10 and 1.9. Luckily I already upgraded tot 1.9 when this happened).

Talking about upgrading, moving from Zend Framework 1.5, 1.6, 1.7, 1.8, 1.9 and 1.10 hasn’t always been painless. A couple of times sudden changes to their API have been made. At some times temporary backwards compatibility was provided, but not always. But that I can forgive, that’s why they’re major releases.

So currently I’ll probably be stuck (as in bug fixes and security updates) with Zend Framework 1.11 when it’s out. Zend Framework is a open-source project so I could always fork the project myself and customize it myself for our own purposes. Even so I’m disappointed with the course Zend Framework went (or seems to be going). The biggest problem with Zend Framework I think is that it’s more of a big collection of classes than a solid framework. Don’t mistake me here, most of the components are very solid. But if they would’ve kept the core small (that being the MVC part and related components) and had moved most classes to the ZendX namespace, such as the webservice classes, they could’ve kept the major releases to a minimum.

Upgrading Ubuntu server delayed for next LTS version

Today at work we decided to wait for the next LTS version of Ubuntu, 10.04. Currently we run 7.04 which is no longer receiving updates. For a while now actually. This summer I worked on planning the upgrade process from 7.04 to 7.10, and finally to 8.04. Which is the current LTS version.

I was able to do a dry run upgrade on our backup server. So I was able to document every step of the upgrade process. Ubuntu upgrades nicely and from 7.04 to 8.04 there are only minor changes that need to be done in our configurations. Even the HP iLO software, for which support on Debian based systems is a bit vague, works out of the box with a native driver. No longer do I need to manually compile the HP iLO driver after every kernel update.

Originally we planned on doing the upgrade somewhere this month or December. But due to tight schedules (it’s quite busy for us) January or February seemed be more likely. Since 10.04, the next LTS version with support until April 2015, is out in April 2010 it likely doesn’t hurt to wait a little bit longer. As far as I know every LTS version so far was easily upgradeable to the next LTS version. So I expect upgrading is going to be a breeze. But of course, I’ll be running tests first when 10.04 gets released.

Why not upgrade to 8.04 first and run that first for a couple of months? Well, support for 8.04 ends in 2013, so 10.04 gives us more years of updates. Also, the upgrade process takes (down)time, time to get there, man-hours that need to be paid etc. etc. Further more, without a doubt, with every upgrade there are some issues going to arise. Small and trivial or stuff that brings down every website that’s running on it. Resolving these issues also takes time, which delays the progress of other projects and what not. By skipping yet another version I think we’ll actually save time.

I’m looking forward to it actually. On of the cool things I’m looking forward to is being able to upgrade Zend Framework from 1.8 to 1.9+. I’m also planning to use memcached and perhaps some PHP optimizer to greatly speed up some of the webapplications. And of course, Perl 5.10 (perhaps 5.12 by then?). Although we, unfortunately, don’t use Perl for our websites I like to keep Perl up to date as we use it for several system administration programs. CouchDB also caught my eye :-).

OK, enough for now. Bedtime :-).