Creating web-based applications using Symfony is extremely simple. This is something I stated last month in my post Symfony : Who Needs a Development Team?

Over the last 2 months I have created all modules that enable alpha release level functionality and at the moment I am attempting to secure the system.

This is where the true mental arithmetic begins. Creating the modules and UI for them in Smyfony is easy. Securing them is a different matter altogether. Security is one of the most difficult aspects of the appliciation to design. Getting it wrong can result  in major issues.

Luckily, Symfony has an active community that will help as and where they can – which is great when learning how to get the best out of a framework. This same community has provided many plugins for a vast array of uses and this adds extra value to the use of Symfony. One plugin that initially caught my eye was sfGuard. Here is the sfGuard description :
The sfGuardPlugin is a symfony plugin that provides authentication and authorization features above the standard security feature of symfony.It gives you the model (user, group and permission objects) and the modules (backend and frontend) to secure your symfony application in a minute in a configurable plugin.

After installing the plugin via the instructions here I quickly discovered that it secures at system level. System level security is great for applications that have very generic user groups – but most applications aren’t like this.

I need item level security. This allows me to specify specifically what a user can and cannot Create, Edit, View or Delete. If I have a multi-site blogging system and an Editor is assigned to each site (much as an Editor is assigned to one magazine or newspaper) – Having a system level securitiy implementation means that groups are created like this :

• Editor
• Journalist
• Proof Reader

Having 3 sites means I should have 3 editors – one for each site. Giving each Editor the “Editor” privilege doesnt prevent them carrying out “Editor” functionality within each others site. This is one area where sfGuard falls short.

In creating a secure solution I am in half a mind whether to extend the sfGuard plugin to meet my needs or create an inhouse solution of my own. Extending the plugin or creating an inhouse solution means the alpha release date has to be put back. Also – extending a plugin is a bad idea as it means that any extension to in, in its current version, could be made redundant if a new version of the plugin is released.

Decisions, decisions…

Categories: ALM, Programming, Requirements

I have recently been developing an application on a WAMP stack and found the exhaustive process of programming a framework counterproductive. At the moment my development team consists of 1 person. Me.

In order to maximise my time I found it necessary to investigate some of the available PHP frameworks that were on offer. Here are the key ones on offer :

1. Zend
2. CakePHP
3. Symfony
4. Seagull

There are many other frameworks available, but the ones highlighted above are my take on the best in the market.

After reviewing the frameworks on offer, I decided that the Symfony Framework was the one for me. I didn’t feel that PHP4 support was necessary and I wanted the framework code to be that bit more optimized. Programming for backwards compatibility means workarounds are necessary. Items such as MVC, caching, ORM were my main review points.

Onto Symfony itself.

I had read some reports of people having some difficulties understanding the folder structure that Symfony uses before I made my choice – but it turns out the people having the difficulty don’t really understand system design. I find the abstraction refreshing and after 1 week I now find it all straight forward.

The most difficult part of creating a viable application in Symfony is designing the GUI. Creating the business logic is as difficult as creating a database schema – one of the most pleasurable aspects of building a web application. Symfony takes the schema and creates modules containing all the functions necessary to update each table.

e.g If you have a notes table as follows :

`id` int(11) NOT NULL auto_increment,
`content` text,
`user_id` int(11) default NULL,
`created_at` datetime default NULL

… Symfony will create a module to interact with this table and create, retrieve, update, delete (CRUD) records in it. This is actually implemented by the Propel framework which Symfony has utilized for database abstraction.

It is this type of programming that is the usual repetitive mainstay of developers until they build up a library of low coupling modules. Since my development resources are so thin – my needs dictate that this unnecessary expenditure is focused in other areas of the systems development. In 3 weeks* from now Symfony will have created a functional application that just needs the GUI (read:: template) designed.

For this the Symfony Framework provides helper functions for creating forms, links, AJAX calls to name only 3. The possibility also exists to implement the Smarty Template Engine with Symfony as well – so I could theoretically outsource the template design – if I wanted.

It is for the above reasons that I ask the question : Who needs a development team?

Frameworks do all the leg work for you. The laborious tasks of writing SQL, adaptors for each database, individual modules that interact with the database are all taken care of. Symfony even creates the initial basic front end for you. All the developer has to do is add additional functionality, handle the interface for many to many objects and validate inputs. It will almost be embarrassing to say I programmed the application when it is released.

*3 weeks = 20hrs development time per week

Categories: ALM, Programming