This is a technical post – you can stop reading now if you're not into web development!
We've been continuing to develop the spec that we recently published for the toolkit.
Several options for development have emerged.
We outline these in our Technical Options Report.
We'd welcome any comments.
CycleStreets has secured £27,000 of funding as a winner of Geovation – GeoVation is an Ordnance Survey initiative and forms part of the Ideas in Transit project with funding from the Technology Strategy Board and the Department for Transport.
7 thoughts to “Toolkit: technical options report”
Absraction is mentioned (twice) as a negative thing. Being able to work at a higher level of abstraction is usually regarded as beneficial (improves development velocity, quality and maintenance). As long as you still have access to the low level stuff (e.g. the underlying HTTP request and response primitives) when needed, you shouldn't lose any power.
If Zend is a front runner but you are concerned about speed ("due to many queries being run"), perhaps this could be quantified by doing a small prototype. Then you could make a judgement based on the results and the anticipated volume of traffic (which I guess will be less than CycleStreets?).
I agree that abstraction is a good thing. The reference here is really to the issue of where a framework presents too much abstraction that it prevents you overriding things easily, or really understanding what's actually going on under the hood. But in general, yes, a good thing, and definitely very important for development speed.
Personally I'd go for Drupal like a shot, but then I'm a pragmatist more than an idealist and I know how Drupal can facilitate writing complex web applications. It's also a very-well-known content management framework and rapidly growing in popularity. Drupal 7 has some very neat features that move Drupal further away from a CMS and towards being a general-purpose web framework.
Not sure why you think Drupal themes have a security problem? Any code, whether module or theme, hosted on Drupal.org is looked after by the Drupal security team. They're pretty good on dealing with security flaws, often finding them themselves. Themes generally only need to take care with escaping output, while modules need to filter inputs and check user access permissions. I'd seen many more security patches for modules than themes – usually XSS or access related problems.
While I can understand the aims of the MVC software pattern, and it's benefits in some circumstances, I'm not personally convinced that it's particularly relevant to web-based client-server application development. You can even argue, a little, that Drupal has MVC features: the menu callback system is the controller, the models are nodes (entities in Drupal 7) and the views are provided by the theme layer. Drupal's Views module could also be seen as a nice implementation of MVC Views :)
Drupal has excellent code review and automated testing tools. In fact patches to Drupal and contrib modules are all tested automatically these days.
Yes, use jQuery for JavaScript.
Perhaps the Zend Framework vs. Drupal argument could be decided by answering:
* Do you want the flexibility of lots of loosely-coupled framework pieces from which you build the system, or is a ready-assembled website framework that you can easily bolt bits onto more useful? How "custom" is this application?
Perhaps the Drupal vs. Rails argument could be decided by answering:
* Are you building a website with a small amount of external API, or an internet application with a small web presence?
For the former, I'd go for Drupal, as it provides a powerful web site out-of-the-box, that speaks XML-RPC, SOAP, RSS, etc. and has lots of ready-made modules to bolt-on typical web functionality. For the latter I'd probably recommend Rails, so you can really tailor the application and make it efficient, without worrying too much about fitting in with code other people have written.
Oh, one other thing to think about: what possibilities are there for this project to feed back into the open-source community? If this is a possibility, I think choosing a development method that facilitates building a community of users and developers would be hugely beneficial for the long-term maintenance and development of this tool. I know that Drupal has a strong community (if your module is on Drupal.org you will get people using it and contributing ideas and patches!), perhaps Zend Framework and Rails communities exist too?
Thanks for these excellent comments, Anthony.
The security comment on themes was only what I'd read – the word seems to be that themes are not as tightly controlled as the modules. Minor point, though.
In general, the site is very much a web application rather than a website, and will be heavily custom, if that makes sense. We're about to publish a draft module set, which is effectively a class structure, and it's very clear having done that that a lot of custom code is going to be needed. An example is the forums aspect which will go way beyond a standard forum system, making an off-the-shelf library/module in any language unlikely.
The community question is a key one. Drupal certainly has a strong community from what I can see; I'm not so sure that Zend does as it's newer. Rails definitely does seem to, with Github providing a good amount of material. For instance, this e-mail reply parser rubygem on Github would probably do the job out of the box, as a brief example.
From what I've heard about Drupal, if you want to bend it beyond the modules that are available, you'll find it very difficult, or that it will take a lot longer, as you try and break the module/plugin before getting it to do what you want, or to theme it as you need it. On the otherhand, with Rails you can just either update the library or monkey patch the code.
Rails has a massive community on Github, and is very extendable and flexible. You can override things as needed. It is designed to be good at building with RESTful sites/APIs. Rails promotes a test driven development process, which reduces breakage, and makes it a lot easier to refactor code. I work with it all day, and have plenty of experience that I'd be able to pass on. If there is a lot of custom development, or off the beaten track development then Drupal will be more difficult, wheras Rails would be a more natural choice since you can design everything from the ground up, whilst pulling gems to do various things. I would vote for Rails.
After much consideration, I'm pleased to announce that that we've selected Ruby on Rails as the chosen framework for this project.