Monday, July 26, 2010

Regretting Codeigniter

Once upon a time there was a legacy PHP application. It was written with no particular framework in mind, and no particular structure to where code was situated. For a while, it even used ADO DB, ODBC and MySQL to access the same database. Yeck.

Then one day, a developer came along. He tried to make improvements to the application, to make it easier to maintain and to make it easier to add new functionality to the product. He normalized database access to just use MySQL, and tried to at least arrange business functionality into libraries, with similar functions grouped together.

This was fine for a while, but things were still rather haphazard, and the developer knew there was plenty of room for improvement.

He decided to impose an MVC framework on the legacy application, to help with new developments. But which MVC framework to use, he was not sure. He had to make sure he could to session and authentication from both the legacy code and the new MVC code. He also had to make sure that the framework models had to be flexible enough to handle the legacy database, without having to visit every program in the system.

The developer was new to MVC in PHP. He'd worked with MVC in Java, and had a pretty good idea how it was supposed to work, but applying the same principals to PHP was going to be interesting.

He tried Zend for a start, and managed to get authentication and shared sessions working, but Zend was just messy to read. The elongated class names hurt his eyes, and threatened to turn one line of code into several, just because of where the class lived in the code structure.

While he tried to decided, he worked on other PHP projects. These projects were fresh-ish. They had the opportunity to start again, but were often based on previous projects to try and get some code reused.

One of the projects used SMARTY Templates. SMARTY was but one part of the MVC equation, but the way the developer ended up using it was very nasty. SMARTY also introduced it's own mini language, which was supposed to introduce a degree of independence from PHP. But nonetheless, it was another language, even it is wasn't PHP, and would still present a problem for non programmers, so why bother. Never again would the developer touch a template system not already included in a MVC framework, and never again would he touch one that tried to introduce a separate presentation language, when the native one was perfectly serviceable.

For another project, he tried CakePHP. CakePHP was very young at the time, but seems to have some reasonable documentation and a community that was excited about what it offered and a development team that was excited about delivering that offering. CakePHP was yummy and great for fresh projects. Favouring convention over configuration, and tools to automagically generate code for models, views and controllers, puuting together the basics for even large projects was fairly easy. CakePHP even allowed some configuration of models to allow for legacy databases. The only downside was it's session and authentication management. Tried as he might, the developer could not find a way to simply include hooks for his legacy application into the CakePHP framework to share session and authentication data.

Finally, the developer found Codeigniter (CI). CI was also MVC based, and also seemed to have a community and development team that was excited about the framework, as the CakePHP community was excited about theirs. Plus, CIs models were super flexible, and used Active Record for database access. This would allow the developer to handle all the weird intricacies of the legacy database. Confident in his choice, the developer integrated CI with his legacy application that would allow access to the session and authentication functions of the legacy system, and allow new parts of the system to be developed with MVC in mind.

The developer passed the new version of the product to his team members, and off they went. The legacy application would live a few more years and have new life breathed into it.

The developer went back to his CakePHP projects, and loved them so. He spent alot of time, alot of good times writing new functionality, quickly, easily, cleanly.

Then one day he has reason to revisit the legacy application and CI, and it was not as he would have liked. He discovered that Helper Libraries weren't actually classes. They were just collections of regular functions and could not be overridden the was a normal class could. He discovered that the flexibility of the model was like being offered flour, water and yeast and being told it was bread. There was still also of repetitious work to be done, and it made him yearn for CakePHP.

Months later, the developer sits alone. His team has gone and he must live with his choice. He once went looking for an ORM tool to make modeling, and especially modeling relationships easier. He thought he found a savior in DataMapper OverZealous Edition, but it was not flexible enough to handle the legacy database. He has not looked at Doctrine yet, but he's not sure he wants to. Anything less than CakePHP is just flour, water, yeast and sugar that tastes like the salt in his tears.

The developer has considered Lithium. Not in the medicinal sense, silly, but another MVC framework, born of CakePHP but with a different philosophy of being lightweight and taking advantage of advances in the PHP language. Unfortunately, it is because Lithium will only serve PHP 5.3 the developer can not use it. He must support 5.2 for the sake of his legacy application.

The developer has even found a way to integrate newer versions of CakePHP with legacy code, so the session and authentication information can be shared. He's just not sure if he can safely integrate his legacy PHP application, CI and CakePHP all in one product. But the more he things about it, the more he thinks he must try.

The developers sadness flashes red with anger. He regrets choosing CodeIgniter. He'll ignite the code, all right. Ignite the code and make cake from its ashes.

No comments:

Post a Comment