Thoughts on plugins with Umbraco 5

Wednesday, December 01, 2010 by Aaron Powell

One of the features that people really love about Umbraco is just how extensible it is, you can create your own applications (back office sections), data types, macros, you name it. But there is one thing that Umbraco 4 has suffered from, and that is a lack of best-practice around how we provide extensions to other developers.

For example if you're creating a custom DataType where do you put it? Well the DLL will go into the ~/bin folder, but if you have a user control (ASCX), CSS files, etc where do they go?

Also, if you're putting every extension into the ~/bin folder it can become quite large quite quickly.

This has been a source of confusion among Umbraco developers and something that we want to address in Umbraco 5.

Introducing the Managed Extensibility Framework (MEF)

Shannon has already done a good blog about MEF and how we're looking to use it for controllers in Umbraco 5, and currently MEF is going to be playing a big roll in how we go about producing a plugin engine.

If you're not familiar with MEF it's a framework which Microsoft added to .NET 4 (but was available earlier previews of MEF supported .NET 3.5, but that's beyond the scope of this blog) and it's a way which you can create applications which are of a pluggable nature. In fact MEF is actually quite widely used, Windows Live Writer (which I'm writing this in) uses MEF to create extensions, and Visual Studio 2010 uses MEF for plugins. So naturally this seems like a logical way to go with Umbraco 5 and a plugin model.

What we're currently thinking

Here's what we're currently thinking with regards to how we can use MEF to make extensibility easier for Umbraco. Imagine if you will the following structure in your Umbraco 5 install:

Plugins
- DataTypes
- - MyCustomDataType.dll
  - uComponents.DataTypes.dll
- Trees
- - FlickrMediaTree.dll

The idea behind this is we'll break down the plugin components into logical blocks, separate folders for DataTypes, Trees, etc. This allows a much quicker view of your file system and what is where. For example I will know that if I want to find my DataTypes they are all in the ~/Plugins/DataTypes folder.

We want YOU

Obviously at the moment we're far from a final set decision on how this will look in the final shipped version of Umbraco 5 and most of us on the core are not extensive package developers so we're really looking for feedback on this.

As I said extensibility is a very important part of Umbraco and we want to make everything easier for developers so if you have some thoughts please let us know.

PS: This blog is more about the design of the Umbraco 5 plugin model, not the implementation (other than we're looking at MEF for this). Technical implementation (i.e. - how to code it) is a topic for another day ;)

8 comment(s) for “Thoughts on plugins with Umbraco 5”

Lasse Eskildsen Says:
01 Dec 10 @ 12:02 GMT+1
Looks great!

Any thoughts on the package architecture?
Morten Bock Says:
01 Dec 10 @ 01:29 GMT+1
Like Lasse, I am wondering how this would work for packages that contain more than one type of plugin. It might have both a datatype and a tree.

Would that mean that the package would have to separate out it's datatypes to separate dll's, or would there be other ways to hook up in case you don't want that (For example a non-MEF way)?
Aaron Powell Says:
01 Dec 10 @ 01:39 GMT+1
The above mentioned way would require data types and trees to be in separate assemblies (or alternatively the assembly replicated across multiple folders).

In what scenario would shipping a single assembly be of more benefit to consumers of a package than having it broken down into logical blocks?

At the moment the thinking is that there will be one way for a plugin engine, be it MEF or through some other manner, but having multiple ways to provide a plugin can lead to confusion (which way is the 'right' way?) and complexity for maintainers (plugin A is in the ~/plugins folder but plugin B is in ~/bin).
Anders Burla Says:
01 Dec 10 @ 06:16 GMT+1
Nice to have this topic out in the open.

We have just released the Tea Commerce package for Umbraco and has learned alot about packages and the creation of these. I dont like thinking of breaking your project into lots of small dll's but a better way would be to have a specific way of structuring files and folder within the plugin. So you have /plugins/TeaCommerce/.. So all files for a plugins is in this specific plugin folder. And then the folders coupe have a naming like - usercontrols - datatypes - admin section etc.
Richard Soeteman Says:
01 Dec 10 @ 08:02 GMT+1
Thanks to announce this early in the process, In the current version of Umbraco the undocumented standard is to create a folder into the plugins folder in umbraco and store all items there. Allthough binaries always end up in bin.

The nice thing is that in case of package development you know that all files related to that package can be found in that folder.

So I would go for Anders his suggestion.

Cheers,

Richard
Aaron Powell Says:
01 Dec 10 @ 09:56 GMT+1
How (and where) to place CSS/ ASCX/ etc will be covered in a different blog post ;).
That's a whole bigger topic, this is more about small components like data types and trees
Shannon Deminick Says:
01 Dec 10 @ 11:03 GMT+1
As Aaron mentioned, using MEF to load in plugins is for compiled resources, not for content files. The issue currently with having assemblies just dropped into the bin folder and Umbraco having to go find specific types in the midst of tens of thousands of types is a huge performance hit and is not very intuitive. There's nothing stopping developers from creating one package with multiple assemblies and IMO this makes much more sense. In fact in uComponents we plan on segregating out our XSLT extensions into a seperate assembly so uComponents will become two DLLs, one for data types and one for XSLT extensions. This give users of uComponents the ability to choose if they want either/or installed. I think this is a much cleaner and more flexible solution and by using MEF in v5 for this model, it completely standardizes the process.
indra kurniawan Says:
27 Oct 11 @ 12:07 GMT+1
I tried drupal for a very short time and drupal stores all the images, css, javascript in each plugin directory.

I voted to place all files for each plugin in their folder( CSS,images, ASCX, ASMX, aspx)

Thank you