Monthly Archives: April 2008

Open Source CMS?

At the moment at Kent we’re considering our options for CMS. We’ve been looking at enterprise CMS, and had a few fairly impressive demos of their capabilities.
But at the end of one demo, someone asked the sales guy why we should pay almost double the price for a licence than a competitor was asking, and over £150k more than an open source CMS we’d seen. Bear in mind that all the CMSs we’d seen seemed so similar that my CMSized brain had begun confusing one with another.
Their answer was telling: it’s more expensive because it’s better. Trust me.
Expensive is a good thing?
Ok so this isn’t exactly a brilliant sell. But this raises a key point, and one which is becoming more and more prevalent in software development. Is more expensive really better? In fact, maybe freely available open source can be even better still. Not only do you often have the same level of expertise going into a piece of software, but typically the experts are far more numerous. The risks are no greater (no companies going bust on you), and bug fixes and security holes are often spotted quicker and fixed sooner than in proprietary software.
Open source isn’t free
But before we get carried away with open source, it’s worth standing back a little and looking at the real costs of open source. For small applications in small-scale operations, open source is now a no-brainer. If you just want a small blog for yourself or company, why would you pay for blogging software when you have such great open source blogging tools?
It gets a little trickier with enterprise level software. It gets particularly tricky with CMS. The reason is again one of complexity. To get any CMS to do what you really need and want takes time and technical skill, neither of which are free.
Open source is cheap
One of the first things sales people from a big CMS vendor will say when you mention open source is: ‘oh but you’ll just end up spending loads of money and time trying to get the thing to work’. They say this as though this wouldn’t apply to their product. But just say someone could offer me the same level of support they could offer, but without the licence fee.
Why do I want an expensive licence?
Buying in a CMS with a costly licence doesn’t seem likely for us, and is becoming an increasingly unattractive option for institutions and companies with a reasonable amount of in-house expertise. My personal feeling is that the gap between expensive ‘enterprise’ level CMS and open source CMS is closing, and the benefits of paying perhaps as much as £80-100k (or more) just for a licence are becoming very unclear. 

 

Things get blurred when you consider what you’re really getting for a full-on enterprise CMS. The actual licence itself gives you the right to use a piece of software which out-the-box will be pretty much useless for your actual needs. Generally you will have to pay about 20% of the licence each year just to pay for support and maintenance (updates and the like).
Support
And you will need that support. Don’t think for a moment that you’ll buy a CMS, press a button, and all your problems will be solved. All too many people who buy a CMS have this romantic notion somewhere at the back of their minds, because of course everyone wants an easier life. The sorts of issues to be sorted out with the vendor will be: how do you migrate your existing content? Maybe you’ll have to think about content types too. And of course there’s the whole area of permissions and roles and groups, never mind more technical questions to do with server setup, caching, etc.
So now you’ve got through the first 6 months or so. You’ve spent maybe over £100k on your CMS, and it’s not really what you’d hoped for. The new website you’d been promising hasn’t quite happened yet, and maybe the support you were promised isn’t all that great because the vendor has just secured a much more lucrative contract. Would you be in this position had you gone down the open source route?
No promises
Well the answer is: quite possibly. But you wouldn’t have lost so much money. Open source CMS doesn’t promise anything more than a licensed product. But it doesn’t promise anything less. The point is that you’ll still have to do a lot of in-house development, tweaking, fiddling, server configuration, etc. But now you’re doing it without the costly licence looming over you.
But what about that crucial support? Open source means you’re on your own, right? Not so. An increasing number of companies are there to help you, for a fee. Back to money again, but at least you’re now only paying for support, not that ugly fat licence. And even better, because the product is completely open source, and company is able to support it as well as any other. There are no monopolies on support licences.
Drawbacks
So there must be drawbacks to the open source route? I suppose the main one is that there are a limited
number of open source systems which can reasonably call themselves ‘enterprise level’. Plone, MySource Matrix, Magnolia, OpenCMS are the ones that spring to mind, and each of these has its drawbacks in terms of either usability or a broad enough user-base. Each has a company or companies who will support you as much as you’re willing to pay, but again we’re back to the licence model, where there’s that nagging doubt that you’re locking yourself into something from which an escape may be tricky.
Conclusion
In conclusion, you can spend a lot of money on buying a licensed CMS. And then spend a lot more money on support for that product. Or you can get something for free, and spend the money you would have spent on support… on support. Does that sound ridiculously obvious? Few institutions and companies (curiously) feel comfortable with the thought that a free product could ever be as good as an expensive one, even though all the evidence is beginning to suggest quite the contrary is true.

symfony routes

Routing rules in symfony are a way of getting simple url’s looking the way you want. So rather than ugly things that show everyone how your system works like:

matthewbull.net/index.php?id=3&detail=false&category=true&year=2008

you can have things like:

matthewbull.net/id/3/detail/false/category/true/year/2008

Even better than that, using symfony’s routing system allows you to completely decouple a url from your code. It allows this because routing is set through a YAML configuration file called routing.yml. So you can change your url in this file without having to worry about its impact on your code, and changing lots of tests for request parameters in your controllers. A simple rule like:

routename:
  url: /*
  param: { module: mymodule, action: myaction }

will magically pair each value to its name, no matter what order those pairs appear in in the url.

Suppose I didn’t want all the request parameters written out in the url above, just their values, or perhaps a slightly more user-friendly parameter name. Something like:

matthewbull.net/3/nodetail/category

This is no problem to do in routing.yml because you can assign alternative names, default values, or no name at all to the values given in the url:

routename:
  url: /:id/nodetail/category
  param: { module: mymodule, action: myaction, detail: false, category: true, year: 2008 }

which will mean the url given above will be interpreted as follows:

first value you put after the domain name will be assumed to be the id

‘nodetail’ in the url actually mean use the parameter detail with value false

category will be true, and year will be 2008 even though no year has been sent (ie 2008 is the default year)

Routing is a great way to get user-friendly urls, generate new urls for the same code, or refactor old urls without having to touch your code. They are perhaps a little tricky to get used to at first, but fairly quickly make sense. The main thing to realise is that rules work from top to bottom, and the first one to match is used. Quite often problems or unexpected results come from not ordering the rules correctly. Always put more general rules lower down!

symfony

I’ve recently been deploying some symfony (http://www.symfony-project.org/) applications at The University of Kent. I’m pleased with the results.

symfony logo

Symfony is an MVC framework, along the lines of Ruby on Rails, but based on PHP5. It is widely used, including yahoo bookmarks:

http://www.ysearchblog.com/archives/000376.html

and the beta of the new version of del.icio.us:

http://www.symfony-project.org/blog/2007/10/02/delicious-preview-built-with-symfony

Why?

So why did I choose symfony as a framework for web development at Kent, as opposed to the many others (for example cakePHP and codeIgniter)? There are lots of reasons, as I’ll show later. But the three most important are:

  • it’s well documented
  • there’s a good and helpful user community
  • it’s very powerful

Huh?

Documentation? No, don’t need that. Well clearly that’s what a lot of frameworks seem to think. Although most frameworks – and certainly cake and codeigniter – have great communities, their documentation isn’t always great. For example, cake has a kind of ‘getting started’ document and then sort of leaves the rest up to you. Fine if you want to do basic stuff, but not so great if you want more.

Plugged in

The key thing with a good community, apart from helpful advice on forums, is the availability of plugins. Symfony has loads of those, as you can see here http://trac.symfony-project.com/wiki/SymfonyPlugins. Many are pretty esoteric, but a lot are really useful, such as a really nice user security plugin called sfGuard.

OOPs

As for being powerful, the thing you notice first off with symfony is that it’s only compatible with php5. Only? That seems odd. Brave almost. But surely they could’ve tweaked things a little to get php4 support? Once you take a look under the hood, you realise that symfony is totally object-oriented. Inheritance, mixins, overloading, public/private/protected. It’s all there, beautifully structured. What’s great about the use of OOP and php5 is that symfony uses autoloading, so a lot of classes (including plugins) are easily available without lots of includes all over the place.

Less is more

OK so symfony sounds complicated, and in many ways that’s true. The real power of the framework comes from its flexibility. There are dozens of configuration files which let you change many aspects of how your application works, from how the urls appear to fine details in a pre-generated backend system. This power creates complexity. But really, any good php developer ought to be able to cope with this kind of thing.

But the power of the system also lies in its potential to bypass many parts of symfony altogether. For example, you don’t have to use the built-in database abstraction layers. Just use anything you want instead, including (heaven help us!) raw SQL. You don’t have to use the built-in scriptaculous ajax methods (but why wouldn’t you).

Scriptaculous

Which brings me to another nice feature: ajax. Although not unique to symfony, it is nonetheless made spectacularly easy in symfony to do some really nice things with ajax. And I do mean the real asynchronous ajax stuff, not just the javascript eye-candy that has become known as ajax.

Saving time

One of the main reasons for using a framework is to give your code some structure, rather than the usual ordered chaos of a hacked-together website. That’s all very well, particularly for big projects. But a real plus for many developers is the ability to produce web applications quickly. symfony can help there too.

One feature that really helped me recently was the admin generator. Beautiful. I basically made a mini-phpMyAdmin interface in about 5 mins. Add to that the sfGuard plugin for authentication and authorization, and in about 10 mins you have a fully-featured admin system. And it actually looks good too.

There are also great time-savers for things that sane developers hate. Things like forms and input validation.

Summary

symfony is a great way to save time and develop good, maintainable code. It’s a powerful framework, and is surely set to grow, particularly now that yahoo have adopted it for a couple of applications. It’s not perfect, but offers a huge amount of power and flexibility, and speeds up application development significantly.