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.
Extensibility
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.
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.
Extensibility
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.
This comment has been removed by a blog administrator.
ReplyDelete