This project is read-only.

Best practice module combination with parts and type

Topics: Writing modules
Jul 16, 2011 at 6:39 PM

in the meantime i'm learning more and more about orchard but the one thing i'm not sure is how to organise my parts and types.

So is it wise to define multiple Parts and type within a module or is it better to split those all over different modules?

Jul 18, 2011 at 10:22 AM
Edited Jul 18, 2011 at 10:22 AM

There is no generic rule, it is just best to split things into sensible, logical groups.

For instance, the Contrib.DateTimeField and Contrib.ImageField modules are implemented seperately - you shouldn't have to install one just to get the other. The blogs module on the other hand has the BlogPart as well as the RecentBlogPosts part and widget. It makes sense to group these together because they are related. This module also defines the Blog content type - so you are getting three features in one module, but clearly you can't have a recent blog posts part without the blog content type and you can't have the blog content type without the blog part, so one module to encapsulate it all is the best fit.

Anything that might be reusable in multiple modules should be in a seperate module (should you have to depend on the blogs module to get a date-time field? No, so it is in a seperate module).

Inter-module dependencies are fine as well though - blogs may depend on the tags module so that the author of blogs doesn't have to implement their own tagging system - and blogs may also depend on the Users module for certain functionality.

If you want to have a module that lets you turn parts of it on and off independently, you can use the [OrchardFeature] attribute on your classes (along with multiple feature entries in module.txt) to define which parts of the module map to which features.

Jul 18, 2011 at 8:11 PM

Well, there is a finer-grain: features. It's ok to group several features in a single module.