This project is read-only.

Relations with extra properties/fields

Topics: Core, Customizing Orchard, Writing modules
Feb 5, 2014 at 1:35 PM
First of all, I'm sorry for the weird title, I can't think of a good title for this topic.

We are building a database/site for doctors. They will be able to register all their clients there with all the medication they subscribed. We have a client content type, a recipe content type and a medicine content type. A client can have multiple recipes and a recipe can have multiple medicine. We use the content picker field for this.

When a new recipe is created, the user has to add medicine to that recipe. The medicine has several fields that are always the same for that medicine. But it also needs to have fields that will be different for every client. For example, Client X has to use aspirin 3 times per day and client Y has to use it 5 times per day. We are looking for a way to implement this in Orchard.

At first we wanted to make a copy of the content picker field and add extra properties to it, so that the user can pick a content item and then fill the rest of the properties after that. The problem with this solution is that we don't know how to make those fields/properties configurable, we don't want to hardcode them.

A better solution would probably be to create another content type where we can add those extra fields to and then build some kind of multi content picker field, where the user has to pick a medicine and when he enters the extra fields, it will create a new content item of the new type and add a relation between the medicine, recipe and the 3th content type. But we also don't really know a proper way to implement something like this.

So could someone help us out? Maybe you know a better solution than the 2 we thought of or maybe you can tell us which one is the best solution and how to implement it.
I hope my explanation is clear enough to understand, it's a bit hard to explain. Please let me know if you need to understand more.
Feb 7, 2014 at 11:46 AM
You could to the following:
  • Leverage only the Content Picker script and invoke it from code just for the sake of being able to select other content items, but don't use the field directly. (E.g.:
  • Now you have to handle the event of a content item picked yourself. This is desired as you now don't want the default Content Picker functionality. On the client-side handle the event, and add the item to a list where there are additional fields you need (like dosage).
  • You have to store this list now yourself. Basically on the client side you let the user build a list where there are items with a content item ID (the one picked) and values for the other fields. You have to build a view model for this to handle the POST and also store this somehow (I'd do this in a serialized field inside a content part if you don't need to run any queries on those values like "what is the average dosage for Aspirin among all the recipes").
Feb 12, 2014 at 8:08 AM
Thanks for your ideas, we will try to implement them soon, I might have more questions then :P.