The pre-framework era
During my web development career I had to accomplish a plethora of tasks for various projects. Database operations, content policies, forms and authentication rules which would eventually grow to build to complex back-end applications and websites. At first it was really exciting as it helped grow my knowledge on PHP and application design. Yet, the more the time was passing the more I would end up with feeling that I was spending it in not the most productive of ways.
I would create complex forms manually and write code that applied the same validation rules again and again. I would manage user authentication through custom functions, unique to each project. I had to put up with code spaghetti, mixing business logic and presentation and I would have to manually apply security rules (escaping etc.) to each database query and each string output to the browser.Yes, something was very wrong… it felt like application development was not fun any more, but more something of a repetition…
Then, it occured to me…
And then it hit me. “What if I gathered all these stuff I have already made into a bunch of classes, which I can use for every client project from now on?”. It was a great idea. So I decided to to come up with my own set of tools :
- A Database Layer. A small class which would automagically escape my queries and return results either as arrays or object arrays. Eventually it evolved to a Database Abstraction Layer as I added more and more methods which would enable me to read and write data to my database without writing a single line of SQL in my main application.
- A Router . I decided that serving all content through a single “index.php” file was the best practice. Moreover, as the framework was modular I would not have to write application-flow-control code. The router would include the appropriate PHP file and serve output.
- A Template Engine. No more code spaghetti. Business logic comes from application modules and presentation comes from html files containing smart tags. The template engine would parse those files and replace smart tags accordingly with escaped data from the application
- A Form Builder. Some forms I had to create for a project were more than 100 fields long. Designing that form using plain html was a real pain. I decided to develop a class which would serve forms through the Template Engine by parsing an XML file describing the form.
- A Form Validator. A utility class which would validate form contents through a set of rules defined on the form XML file. Specialised validation would be carried out through callbacks to php functions.
- A Cache Layer. My Thesis is on caching and replication, and thus I completely understand the importance of caching. No need to query the database about the same things again and again, no need to rebuild dynamic pages when nothing has changed.
- An authentication Layer. A very agile library which would contain all the functionality for proper authentication and user management.
My own personal framework
So, without too much planning and after understanding the needs of it I have managed to create my own framework. I was really proud of it. It was fast, secure and would power up many medium-to-large scale web applications. I was the king of the hill. But this did not last for long. I always had to create new functionality, add more widgets, modules etc. I had to make it feature rich by adding more and more functionality. I didn’t like that, especially after thinking that much of the functionality I had to implement was already implemented in other applications by fellow programmers all over the world. Why should I build a new RSS parser, since magpie is already on the loose? Why struggling over Akismet implementation when it comes right out of the box with WordPress ?
Maybe a not very bright idea after all
When the company I used to work as lead developer hired an assistant developer, I realised that for the first months I would have to spend more time getting him to understand the ins and outs of the framework rather than having him assisting me. And then it finally occured to me… no matter how beautiful my framework it was not feature rich as it was far away from popular with fellow developers. In fact it was only used by around 12 developers in my company… It had to mean almost nothing compared to the momentum of other Open Source PHP frameworks receiving love and support from developers all around the world!
Opening the pandora box
I decided to google for php frameworks and I managed to gather quite a few of them. All off them would offer around the same functionality:
- MVC architecture (plain, clear and simple to build and extend)
- Database abstraction layers ( hurray, no more SQL and no more sql injections)
- Routing ( no more complex code on what gets included when)
- Templating (do away with code spaghetti)
- Form builders and validators (because the biggest part of user interaction is based on forms)
- Caching ( don’t rebuild already built fresh content)
- Authentication ( secure way to distinguish your admins from your visitors)
No matter if the offered functionality was almost identical, the difference was on the mentality and style of each system. We will get to the differences of each post in a new post
Final thoughts
I picked up CodeIgniter and (later) Yii for my application development needs and I have to admit that this choice changed my developer life forever. No more had I to worry about forgetting to escape user data. No more would I have to dig into big applications to see what is loaded when. Both these frameworks have made my life easier and turned PHP into a Performance Rapid Application Development tool. In the near future I aim to write a complete presentation for those two frameworks and how they can be a real life saver for some problems
What are your opinions on frameworks? Do you still prefer raw PHP? Still sticking to your own framework? What has made you choose your current framework?
