Welcome to

thirty4 interactive

Just another company blog

Automating symfony application builds

February 7th, 2008 by Damian Hodgkiss

When developing a complex, structured web application proper testing is a very important aspect that is often overlooked. By using unit and functional tests you not only verify the code works as it should, but you are also able to catch things that break during the ongoing development process.

Writing tests alone can often be a tedious task, but it is a task that is well worth the effort. Symfony provides steps to make testing core units and browser output a breeze. You can use unit testing to ensure core functionality of your library classes are working as expected and functional testing to ensure URLs are working as expected. By including a test for every module action you are able to catch anything that breaks as a result to code refactoring and forces an unexpected HTTP return code.

Writing Tests

I will try not to repeat any of the information in the Symfony Book and just provide a basic overview of minimal testing you should be doing.

For each library class you develop, you should have at least one test unit which tests the expected behavior of every public method. This will ensure the foundation of your application works correctly. Each method test should check to ensure the correct behavior, the incorrect behavior and that the correct exception is thrown for a particular action.

To go beyond core behavior testing, you should also verify every action your application exposes works as expected. This means they should all be checked for a valid HTTP 200 response code and should include various other checks where possible. For example a download redirection script should check for a valid redirection. As well as various HTTP checks you can also check the output does not contain various PHP warning messages which don’t always affect the application but should be fixed regardless.

Package Automation

Every application has a different packaging method whether it be create a PEAR package or just compress the directory contents. This task can also be automated by creating the required steps in a task. An example task may run a freeze, create a valid PEAR package.xml, run pear package and unfreeze the project. For flexibility the task should take optional parameters such as version or package filename information.

Nightly Build Automation

Nightly build automation can be accomplished in various ways using something as simple as a shell script in crontab right through to an application like CruiseControl. We prefer to use CruiseControl because it provides flexible scheduling options and comes with a vast array of plugins to provide various actions. While primarily aimed at Java applications, the flexibility of CruiseControl makes it suitable for almost any project.

Depending on your goals, your nightly build automation should go something like checkout trunk from SVN, run unit and functional testing, build a package, upload package, e-mail the results. This allows you to not only have a historical reference of every build, but also gives you early notification of test failures.

Conclusion

Proper testing and development processes are often overlooked by the average PHP developer mindset, but by going that little bit further you can ensure you produce a well developed, well tested application with fewer problems likely to appear when it is published for public consumption.

While test driven development is not required, detailed unit and functional testing in any development process is sure to decrease the likely hood of problems.

Posted in Development | No Comments »

Symfony vs. CakePHP: My Experience

April 17th, 2007 by Damian Hodgkiss

Having used CakePHP 9am-5pm for the last year on a large (150+ table) commercial application due to a clients requirements, and using Symfony for other web site applications I decided to write this article to compare my experience using both PHP frameworks concurrently.

I will say straight off the bat I am bias for the Symfony framework, but I have tried to share my experience also being fair to CakePHP where possible. My opinion is that Symfony is a very elegant, flexible framework that I can use in any situation while I feel that CakePHP has many limitations and annoyances in any large application that I find every day.

I find CakePHP’s biggest flaw to be the model layer. If this used an ORM approach much like Propel or Doctrine I believe the data side of CakePHP would be far easier, especially in large scale applications.

Installation

Symfony

Installing Symfony may be performed in two ways. The first using the sandbox allows you to download the framework and develop your application inside the directory structure.

The second way to install Symfony is to globally install the libraries as a PEAR package. This is achieved by adding pear.symfony-project.com to your list of PEAR channels and then performing a pear install symfony/symfony.

You may then use symfony init-project to create as many projects as you like on the same machine.

CakePHP

Installation of CakePHP is done on a per application basis by first downloading the framework, and then developing your application inside the directory structure. This makes getting up and running very fast with the only requirement being to configure your database settings.

Configuration

Symfony

Configuring Symfony may be a rather simple task or a rather complex task depending on your own requirements. Symfony uses .yml text based configuration files which are compiled to PHP files for caching purposes. Basic required configuration only consists of database and routing settings, however there is a host of other optional configuration steps available from configuring meta attributes in your HTML right through to configuring validation attributes. Configuration by also be performed on a per-module basis overriding the default configuration for modules and individual actions.

CakePHP

Configuration of CakePHP is rather simple, with the only requirements being to configure the database settings and the routing configuration. All of the main configuration is done via core.php which has a few other settings but most users will not need to touch these.

Views

Symfony

Symfony views are basically raw PHP template files with variables exposed via the action. You are provided with a large amount of default helpers allowing you to perform Javascript and Form operations with ease.

CakePHP

CakePHP views also uses raw PHP template files with variables exposed via the actions. As with Symfony, CakePHP templates also support a large amount of default helpers, with the main difference being they are object based instead of function based.

Models

Symfony

By default Symfony uses a third party ORM known as Propel for its model layer. The configuration for Propel works by defining your schema in an XML (or .yml) configuration file which defines the entire database including all of the tables and foreign key relationships.

The advantage of this method is each model then has a class generated for it, which you may extend with your own functions providing a great data object based environment. SQL for the engine of your choice is also generated, and optionally loaded in to the database server for you.

CakePHP

CakePHP tackles models in a completely different way, by defining your models (tables) in classes. Each class is then not used as an object, but instead returns an array of data. I really dislike this method of data modelling, as the data returned is far too static for my liking often consuming vasts amounts of RAM when used recursively. I believe CakePHP version 2 will use objects, I am unsure what affect this will have on porting existing applications.

If you enable DEBUG 2 in your configuration file you will also notice that CakePHP issues a DESC table command on each request to discover the database structure dynamically. While it does support caching the data, against I am not fond of this method at all with a lot of queries being performed on each request.

Validation

Symfony

Symfony uses form validation which is performed against the GET and POST parameters submitted in the request. The validate.yml configuration file is a flexible configuration file allowing you to specify what parameters are required, what error message to display and what validator to use along with any parameters to pass to the validator.

CakePHP

The CakePHP approach to validation is in the form of a $validate array in each of the modules. Validation is performed on each of the fields when you attempt to save data to the model. The validation is rather simplistic allowing you to check each field against a regular expression pattern.

Routing

Symfony

Routing in Symfony is performed by modifying the routing.yml configuration file. You may define unlimited routing rules which use regular expression to match URL paths which point to modules and actions. You may also use :parameters to pass in to actions also supporting default values.

CakePHP

Routing in CakePHP is performed by modifying the routes.php configuration file. CakePHP also supports defining unlimited routing rules using the $Route->connect() function which also use regular expression to match URL paths which point to a controller and action.

Debugging

Symfony

Symfony debugging is performed by enabling the debug option in the application settings.yml configuration file. By default, you are given a production, test and development version of your application and this is automatically done for you in the development version.

Provided you have setup the Apache configuration properly so the /sf alias is able to access the Prototype Javascript Library you are presented with an attractive overlay debug panel at the top of your screen allowing you to view all aspects of the request including routing, template and SQL query information.

CakePHP

CakePHP debugging is performed by enabling the DEBUG define in config.php, by changing it to an integer value of either 1 or 2.

Changing this to a value of 1 will force CakePHP to print results of debug() and pr() calls to the screen, while changing this value to 2 will force CakePHP to also display a dump of all the SQL queries performed at the end of the page request.

Plugins

Symfony

Symfony has a vast amount of plugins available at their plugin repository including Javascript library integration, Propel extensions, model layer replacements and security. Some of my favourite plugins include sfFeed2Plugin, sfShoppingCartPlugin, sfGuardPlugin and sfSslRequirementPlugin.

CakePHP

The CakePHP framework does support plugins with its repository located at CakeForge. However the CakeBakery seems to be the place for a large supply of usable extensions. Some that grab my attention include SwiftMailer, Yahoo Geo Coding, Report Creator and the jQuery Helper.

Posted in Development | 7 Comments »

Copyright © 2oo8 by thirty4 interactive