My latest experiment is building a new site without leveraging one of the many MVC Frameworks that are out there today. I decided to approach a new project using the following criteria:
To be fair, my results were a mixed bag, but so far I’m happy with the experiment. The site is not open to the public yet, but you can check out the current version here if you are curious how it is going. Below is a brief out line of the tools I used and the results (good, bad and ugly)!
Let me start by saying that I do not intend to criticize anyone’s code. All of the solutions that I used did their job as advertised and did it well. What I’m providing is my perspective of how doing that job added to or detracted from the ease of creating my web application.
GluePHP was a great front controller. It performed exactly as expected and did a really great job. It handled query string parameters via regular expressions and just plain worked. Rain.TPL was equally compelling. It was super easy to use, fast and did a great job helping me lay out templates. I did experience a problem with query string parameters buried in sensible URL’s without the ?, but it was user error. I’ll explain that more below. 960 Grid System continued to be a programmers friend as it is just so easy to use. I can’t say enough good things about that little CSS Framework.
The Not as Good:
RedBeanPHP is a solution that continues to vex me. I keep coming back to it because it is so darn cool, but it does have some limitations that are frustrating. RedBean excels at dehydrating and hydrating objects for easy database storage. What it does not excel at is referential integrity. I does not handle foreign keys. You can do it yourself, but this means managing decisions about cascading deletes on your own. The whole point of an ORM is hide all the mechanics of that from the programmer. RedBean does not quite see it that way. That’s why I contend that the ORM label is somewhat miss-leading. I expect my ORM to not create intersection tables by default for every join I ask it to make. RedBean does that. The lack of referential integrity is partially what leads to RedBean’s coolest feature, programming the DB on the fly in code rather than writing SQL. It’s that same lack of true ORM design time metadata that prevents it from building foreign keys. RedBean gives you tools to help with this, but eventually you realize that you are implementing those features yourself. For me the ORM of choice question is still outstanding, but if you need an object hydrator / dehydrator then you should look no further than RedBean. At that function it is the BOMB!
My understanding of the Rain.TPL was not as good as it should have been. I was having a problem with clean URL’s and the WYSIWYG features with Rain.TPL. I posted a question and the following Monday the Rain team provided a great answer. Unfortunately I wanted to plow ahead so I converted all my links with query strings to hidden form posts to overcome the issue. It worked and jQuery was excellent as usual in accomplishing this, but it was not an ideal solution. Having said that I still think Rain.TPL is the most compelling and easiest PHP template engine I’ve used to date.
The PHP Framework that I’ve used the most is Kohana. Right out of the gate I started missing some of the Kohana helper functions. I had to locate and update an older cookie management class that I re-dubbed Monster. That plus Formed and RedBean PHP helped me get the authentication working. Next as I tried to build CRUD operations I started writing my own “controllers” which were just objects that go called by the GluePHP class. This worked fine, but I quickly realized that I was lacking a model. Since I was trying to be fast I started adding the additional code around calls to RedBean to achieve more model like behavior from methods in my controller classes. This was a poor architecture, but it was better than writing my own models so that’s what I went with. This meant that the solution was not quite as structured as I would have preferred.
The Road Ahead