Many to Many UI - Checkboxes

Jun 14, 2011 at 10:17 AM


First off great set of modules that really extend the power of Orchard, you really have raised the bar!!

I have been looking at Orchard as a CMS solution and the first thing I needed to do was create a few many to many relationships for my content.  I'm a software developer so the first thing I did was get my hand dirty and run through the N-N documentation this was fine but I wanted to use ContentParts for both parts of the relationship and have attempted to get this working.  I've hit a few bumps along the way, mostly due to my lack of understanding of content parts & types and the shape rendering.  Could you explain the difference between a Content Type, Content Item and Content Part?  I've read and re-read the documentation and think I understand it but then I read something else and I'm not so sure!!

Anyway, needed more than 1 N-N relationship seemed a lot of duplication so I started to investigate a generic solution and I come across your Mechanics module.

I've read through your documentation and have taken a look at your theoretical Economics example.  I understand how you relate your domain Content Items to Sockets and create relational parts that include the Connector to wire up the relationship.  This all seems very logical and succinct.

What I'm not so sure about it the DefaultEditorParadigm, how does this work?  I notice that you render a select box for your ProductToCategory connector, and the "Hidden" paradigm on the  CategoryToProduct seems to hide that realtionship when creating a new Category.  How do you define these paradigms?  As a select box is rendered for your ProductToCategory connector, titled 'Select one', its seems to restricts the relationship to many to one, even though the connector seems to be configured for many to many.  Could you render a list of checkboxes or a multi select list?  If so how?

Thanks for your help,



Jun 14, 2011 at 10:57 AM

Hi Jeff,

Firstly - thanks for your comments, I think you get exactly why I started making these modules :)

I'm not sure if you're using the gallery version or a source enlistment - but yesterday I actually added checkboxes for many-to-many relationships. Actually in an older version there had already been a multi-select list, but then I refactored a whole load of the UI building code, and it just took me a while to bring that back.

So regarding EditorParadigm. This gets set from a SocketHandler (unless you override it with DefaultEditorParadigm) and can now be referenced in If you look at the latest source, you'll see is where I switch between single or multiple select shapes, based on whether it's SingleChoiceParadigm or MultipleChoiceParadigm. I'll be adding further UI paradigms, such as an AJAX search. Basically it's a way to group sets of UI functionality for particular socket types. You can use DefaultEditorParadigm to set it yourself, and then from Placement control which bits of the UI appear. Everything can be controlled - which Finder(s) there are (i.e. dropdown or checkbox), how the connectors and their child UIs render, whether the batch operations selector appears, everything.  If you want to add your own logic for choosing EditorParadigm, you can implement a SocketHandler and do it from the Editing override method there. You can configure a lot of other things from the handler, such as setting DisplayTypes for front-end, as well as adding filters and sorters on the connectors. A lot of the core Mechanics features are just built on those extension points, so you can see some examples of how they're used.

I'll just explain the content type / item / part distinction. A Content Item is a complete unit of content which can be made up of many Content Parts. A Content Part is a chunk of functionality, view code, and business logic; and they're the building blocks for constructing Content Items. A Content Type is basically just a template for a Content Item; it defines which parts will go together to make up the total item, and also defines settings on those parts. Hope that makes sense!

Jun 14, 2011 at 12:03 PM

Hi Pete,

Thanks for your quick reply.

I had just downloaded the latest source when I see your message!  I have loaded this up and can now see the checkbox functionality.

I will need to spend some time getting my head around the Placement/shape/rendering logic before I can fully appreciate how the EditorParadigm works.  I think I get the gist of it but the placement file is throwing me a bit, is there a region called "Finders"?!

Thanks for your explanation of type / item / part, its helpful.  So to clarify, in your Economics module you define a Product type, which is built of parts.  You don't actually define a Product part to use in this type.  If your product required, say a short description, would this constitute a reason to create a Product record and part?  I think the problem I am having is I see Parts as quite generic and reusable, however in this case this Product part doesn't seem much use on its own without it's counterparts.  Does this have something to do with the Attachable configuration?

Thanks for your help,


Jun 14, 2011 at 12:17 PM

The various templates of the Mechanics system have their own zones. So for instance there's a "Socket" shape which is rendered for each type of connector; and that shape has its own child zones. They work identically to the normal content zones, they're just in their own template. I named them all differently to the normal content zones, so it'd be clearer when looking at a Placement file which ones were for Mechanics. It was pretty complicated getting all that working! It's what the Origami module does - allowing you to build compositional views anywhere, not just in content rendering.

I'll be making some diagrams and better documentation describing what zones are there in the default templates. But if you look at Socket.Edit.Compositional.cshtml and Connector.Edit.cshtml, you can see all the @Display(Model.ZoneName) calls.

With the Product content type - if you wanted to add a short description then that's why the BodyPart is there. If you wanted a separate field for a short description/summary, then instead of making a ProductPart, I'd make a ShortDescriptionPart as a unit of functionality that can be reused on anything, just not products. The main reason for making a ProductPart might be to handle things like Price, Postage, Quantity, and so on... Obviously Economics isn't anything like complete at the moment since it doesn't have those! The main Theory project that is actually functioning is Cartography, so that's the place to look for proper examples, although I'll be getting the others polished off soon.

Jun 14, 2011 at 12:30 PM

Ok thanks for your help Pete, I will take a look :)

Jun 14, 2011 at 12:45 PM

Give me a shout if you need anything else. I know the documentation isn't up to much yet! Of course if you felt like writing any, it'd probably be better coming from another perspective, and I'm really struggling to find the time to fit it in :)

Jun 14, 2011 at 1:08 PM

No worries, at this early stage I wouldn't expect much documentation! Functionality always wins over documentation at this stage, especially when you're a one man band!!

Once I get my head around it and working for my scenario I could certainly write up a recipe type doco.  If I use any extensibility points I could certainly write them up too.  It will be a starting point!

I will give you a shout if/when I get stuck!

I've taken a look at your Media Garden project too, looks like it could be really useful for another project I have on my list!  Haven't pulled the source yet but from the overview it looks very useful and a real win for Orchard :)

Jun 14, 2011 at 1:22 PM

Yeah, Orchard provides a really nice base platform to build up from, but it's really lacking when it comes to the serious functionality I actually use in websites I build. Basically I set up these projects to provide everything else I need. The two are designed to have a lot of interaction; for instance with Media Garden, all media actually gets created as Content Items - and can therefore have Sockets and Connectors applied to them. It makes it really easy to do things like adding thumbnails to your content (or in the Economics project I'll be using it for product images), and controlling view and edit permissions over media.