Home » Posts tagged "PHP"

Symfony 2 cheatsheet

A cool Symfony 2 website I ran in today is the Symfony 2 Cheatsheet by David Pérez. It sure would’ve been nice if I had this one around when I just started out with the Symfony 2 project I’m working on (which will be launching soon).

Check it out at http://www.symfony2cheatsheet.com.

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.

 

PHP’s switch-statement bit me in the ass

Since a few days a certain operation in the webshop software we’ve written at work was extremely slow. Adding a product to the basket took forever, like 2 minutes. When adding a product to the basket it checks if there are any related products that should be added to the shopping basket as well. This is a feature we’ve called bundles. You can bundle products together and specify some rules such as optional or obligatory to purchase with the selected product.

In our current database some products can have up to 100 optional articles. Such as extended warranties, memory expansion and so forth (in case of e.g. a desktop PC). After finding the source of my problems I was dazzled. I iterated over the products in my shopping basket with a foreach-loop. Inside I used a switch-statement to see if the related article was optional or not. If not, I would simply do a continue to go to the next item in my list. Or so I thought.

This however didn’t seem to work and after looking up PHP’s online manual I found this:

Note: Note that unlike some other languages, the continue statement applies to switch and acts similar to break. If you have a switch inside a loop and wish to continue to the next iteration of the outer loop, use continue 2.

I was very surprised to read this, totally unexpected to learn about this behavior. I really can’t think of any reason why they did this.

PS: I know adding 100 optional products shouldn’t take that long, but since all our prices are pre-calculated (we have a very extended pricing table with lots of features and conditions) we want to be sure the price is right when they add it to the basket so we recalculate it and update the product database.

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.

PHP 5.2.14 released but don’t get excited yet

Yesterday PHP 5.2.14 has been released, together with PHP 5.3.3. I used to get excited about PHP updates, but no more. This is because of a number of disappointments I’ve talked about earlier. But that’s not really the reason of why not to get excited.

So, why shouldn’t we be excited about PHP 5.2.14? The changelog contains a lot of security enhancements and bugfixes. There is nothing wrong with this, quite the opposite. It’s good! But there’s one thing that is completely unacceptable to me and that’s the sudden announcement of the end-of-life for PHP 5.2.

This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.

Yes yes I know, we can all happily migrate to PHP 5.4, what’s the big deal huh? Well, how about announcing the end-of-life of a product in advance? I don’t mind it being killed of but at least let your users know in advance. I remember PHP4 being announced to get killed off, giving users a good year afterwards to prepare for the upgrade whilst receiving (possible) security updates. Yes yes I know, they said security fixes might be published on a case by case basis. Keyword here is might.

Tell me, do bigger companies and/or enterprises etc. take this? From my experience this isn’t very much appreciated. Organizations need time to plan these kind of migrations.

For me this is again a sign of PHP failing.