Sunday, 14 March 2010

Working on an Umbraco Project with Multiple Developers

Over the past couple of months I've been working with the open source .Net CMS Umbraco, and been very impressed with the breadth of features and opportunities for extension and customisation that it provides. Operating as a one man band, it's very straightfoward to work with the product using the web based UI for most of the development tasks.

However one concern it gave was how to set it up such that in can be used within a development team - with multiple developers working on the same project and how to integrate it with source control systems.

Issues arise from the fact that whilst some content is saved as files on disk (e.g. templates, XSLT macros), others are held in the database (e.g. data types, document types, and the content itself of course).

In order to get around this, we've set up and used the following model - which seems to ameliorate the concerns:
  • Firstly, a single database is set up on a networked server for access by all developers. This means any created document types, data type and content nodes are immediately available to all developers, and they can rely on any IDs used to be consistent.

  • Secondly, each developer installs a clean Umbraco installation onto their local PC.

  • Finally, a companion Visual Studio solution is created. A project can be created within this for the creation of user controls and custom pages as would necessary in any case if such extensions were required. In addition though, copies of all file based information (stylesheets, scripts, templates/master pages, config files, xslt macros) are also created here.

    This being the case, such files can be managed as they would in any other ASP.Net project, and checked into source control as required. The key change to working practice is that they are edited within Visual Studio rather than Umbraco.

    An added advantage here is that you get access to VS.Net's intellisense and colour coding, which I've found to be a particular benefit when editing XSLT macros. There is the downside that you don't get to use Umbraco's own tooling support - in particular the toolbars for inserting fields and macros. However in practice I found that even an fairly novice Umbraco developer soon doesn't require these helpers, and if they are needed, can still be used of course provided the developer remembers to replicate the change into the VS.Net files.

    In order to integrate with Umbraco, a post-build script is set up that runs an xcopy statement to copy the necessary files from the VS.Net project to the Umbraco installation.

    So whenever an edit is made that needs to be reviewed, Ctrl + Shift + B will build the solution, and run the post-build script to copy the files into the Umbraco folder. And loading up the site running on localhost will allow the latest changes to be viewed in the browser.

Monday, 8 March 2010

Switched on Umbraco

Although for reasons I won't go into it looks like there's a good chance the project isn't going to see the light of day, I've been fortunate in the past couple of months to have chance to properly get to grips with the .Net open-source content management system Umbraco.

Having heard good things about it from colleagues and the web community, I was hoping to find in this product the right balance of providing a rich framework for the generic requirements of a content-rich site, whilst retaining the ability to extend as necessary without running into the limits of the product. And I have to say after spending this time working with the system, I haven't been disappointed.

I plan to blog a few specific developments where I've found need to extend the product to fit the needs of the web-site I'm building, but firstly just wanted to highlight the key benefits for me that I've found.

Custom Document Types
Even quite recently I was pitched a commercial CMS product that whilst flexible in it's design, was very limited in the types of content you could represent. Standard article pages were all very well, but a CMS should allow you to add new fields and relationships as necessary to accurately model your content types. Without it, you end up combining data that should really be seperated to support flexibility in presentation, and generally pushing a product into ways it was never really designed to be used.

Umbraco supports this via the concept of document types which you define with the fields you require, and how the type relates to other types within the site structure. Each type can have one or more templates associated, giving flexibility in the presentation for pages with similar content structures but different layout requirements.

Umbraco is built on .Net, so much of the techniques for extension of the system use familiar techniques to ASP.Net developers such as user controls and aspx pages.

The most efficient way to provide custom functionality when all you are looking to do is to aggregate information already held within the Umbraco content is to use XSLT macros. The syntax for these can get a little verbose and convoluted if you aren't familiar with it, but there are good examples to work from for many common requirements (e.g. breadcrumbs, navigation and site maps) and to get up to speed.

If you need to go further than this though, it's necessary to spin-up a companion VS.Net project where you can create user controls. By copying the ascx and dll files to the appropriate folders in the Umbraco installtion and creating a macro to "wrap" the user controls, all usual .Net functionality including in-line code and code-behind, events and post-backs can be brought to bear to the project.

Finally, Umbraco itself is exposed as an API with the set of classes available providing ample opportunity for further extensibility - such as responding to Umbraco events like "page publish" and allowing information from within and outside of Umbraco to be amalgamated for display.

Community Code
One of the advantages of leveraging a product like Umbraco is the ability to make use of not only the core product, but also the many community contributions that have been built to extend the product. Sample websites, search tools and image processing controls are some of the ones I've looked into thus far, each of which has saved many hours from building into a custom CMS solution.

Any Issues?
As is no doubt clear from the discussion above, I've been very impressed with this product and am looking forward to working with it much more in the future. There have been many occasions where I've been pleasantly surprised in finding that what initially seeemed like being a tricky requirement to implement has either already been accounted for in the core product, or is easily solved via a simple extension.

One possible issue is that the content editing UI - whilst intuitive and very straightforward to work with - does seem to be optimised for small to medium websites. And that it's tree view navigation structure could get a bit unwieldy if you had hundreds of "news stories" for example.

I've got around this by structuring content for a news section using dated year and month folders, which makes the UI a little easier to work with. And using an XSLT macro the content can be collapsed on the front-end website, where I may not want to break out the stories in the same way. However it still leaves the issue of only being able to provide the CMS user with a single route to navigate to their content - in custom CMS solutions I've built in the past I've tended to provide a search form allow the user to locate the story for edit via a combination of criteria such as date, author, category and keyword.

Another potential concern is that the product whilst fantastic for a one-man-band development, requires some workarounds to support multiple developers working on the same installation. The reason is the combination of some CMS assets being stored in the database (data types, document types and content) and others on the file system (templates, CSS, XSLT macros).

In the next blog post I'll discuss how we have set up our environment to support this requirement, and also how similarly we plan to handle deployment of changes from development, to test and production.