|
Chosing Frameworks: CakePHP |
 |
 |
 |
|
Written by Fred Hirsch
|
|
Monday, 12 April 2004 |
This will likely be my last entry for awhile in the "Chosing Frameworks" series. Mostly, because I did decide that CakePHP was the framework for me. My biggest influences in chosing Cake were - Its very much like Rails, which is my favorite framework architecture.
- Its done with PHP, so its highly portable (much more so than Rails).
- Its just a framework, and is very cleanly coded.
- Its mature, and has alot of user support. Maybe not as much as Rails, but much more than other PHP frameworks.
I'll go over each of these points in some more detail.
Architecture Architecture is basically the design and outlook of the framework. For me, a framework needs only some very basic design principles in order to be usable. First, it needs to have a coherent and easy to use data access layer. This is the layer that sits between the database and the application core. It may contain business (domain) logic, but its main task is to simplify DB access and portability. CakePHP handles this well, using the very mature ADODB PHP library. I have used this library extensively in the past and it is both stable and performs well. Secondly, the management of business logic must have a sound and simple API. I like how CakePHP utilizes a functional domain model rather than the event driven one of PRADO. While PRADO is unique and very interesting, its hard to wrap existing designs for web applications into that model. Cake utilizes a much more common viewpoint for developing various commands that are mapped from the URL. It is simple and complete in my opinion and doesn't require a new way of thinking. Lastly, the interface or view layer needs to allow easy modification by both frontend designers and developers alike. Unfortunately, this is still one aspect of CakePHP that held me back from accepting it for a long time. Rather than using a dedicated templating system, CakePHP accepts PHP code in view templates directly. I still think this is a mistake, but Cake also allows vendor plugins to be developed that allow other templating systems to be used. This doesn't seem to be a simple task though, as even attempts at Smarty template plugins are somewhat incomplete. Adding templating is something that is high on my list of desired features, and I hope it is added in future releases. PHP & Portability Rails is written in Ruby, and while language acceptance is growing by leaps and bounds, it just isn't as widely supported as PHP. PHP is easy to install on both Windows and UNIX platforms, and runs embedded without alot of the extensive configuration that Ruby requires. It is also very easy to create installers for CakePHP applications that simplify the process of creating common web apps. This might seem trivial stuff for developers, but for me portability is an issue that is more important to administrators and users. As such, in-house developers might not worry about whether PHP is portable, and can work just fine with Ruby. My outlook was that I wanted to be able to distribute applications I develop to users which might have only a basic understanding of installling applications. Rails does not make it easy for such users to unpack a distribution and install it. PHP by default is much more easy to manage in this respect. Does Rails have applications like phpBB or Nuke? Not yet, and I think this is limiting its growth. Essentially... PHP affords better acceptance of an application to the common masses. Its just a framework! I am a developer, and I don't need alot of extras in my framework. I don't even want examples in the core. I want to be able to install the API as a library somewhere and be able to reference it with many applications. CakePHP does this with amazing flexability. Not only can you install the framework inside an application distribution, you can also let it sit outside of the install area. This provides lots of options to improve security in the application. There are some nice abilities built into CakePHP. It has a simple page controller that allows display of semi-static HTML. Allows routing through URL rewrite to specific pages, and so forth. It also allows for various communication interfaces such as straight HTML or even AJAX. Other than that, the framework is essentially just the core components one considers as essential to developing a good application. One area that I wish the CakePHP coders would standardize is authentication. Without a dedicated authentication API, it leaves too many doors open for badly written authentciation layers. Maturity & Support CakePHP has been extensively tested and developed for some time now. The documentation of the API is well done and there are numerous tutorials and other materials available to assist in learning to use the framework. CakePHP is not an application on its own, it is strictly a developer tool that can allow for rapid development of web applications. As such, support is completely development oriented. You won't learn how to build a CMS with easy 1-2-3 instructions, but support will provide you information on how the domain layer handles database relationships and so forth. Overall, I've found CakePHP to be my personally ideal framework solution. I plan on following the project and using it in a variety of applications I am planning for the future. As such, most future articles will likely discuss how I have done specific tasks using the CakePHP framework. Hopefully these will be informative, but let me know if you have anything to add. |
|
Last Updated ( 2007-05-30 20:21:34 )
|
