So first of all we need content types and fields.
Our example will be 3 content types:
- Invoices with the fields: tax%, articles (multi lookup), quantity, invoice total, client (lookup)
- client with the fields: name, address, city, telephone number
- article with the fields: article name, price per unit , description
In the example that you can download (link will be provided at the bottom) I went a little overboard with the naming of my fields. But you can clearly see what fields are for article, client and invoice.
All the types of fields can often be challenging to remember all the attributes that are necessary, so I often use this blog to check if I forgot anything.
A good link with explanation about lookups.
Pay attention to this line in his blog:
Checking the field from code showed that the LookupList property of the site column was “Lists/Tasks”, so it was not resolved to the list GUID on feature activation.
Now the way he fixes the issue isn’t that bad, but after looking for some deeper issue as to why it behaved like described I came across another blog writing in depth why and the solution on how to solve it “cleanly”.
The summary of the blog:
So long as you specify Overwrite="true" for Field elements of type Lookup, LookupMulti, TaxonomyFieldType, etc., relative references will work. And you can completely disregard the "created in the same feature" statement in the MSDN reference.
Defining the fields, content type and lists:
Now if you want to define all the content types in a single elements file and all the fields in a single elements file.
No problem what so ever, but when it’ comes to lookup fields you’re going to have an issue… especially when you are creating lists that use these content types.
The chicken or the egg paradox will happen here. You are defining a lookup field with a soft reference to a list that doesn’t exist yet in the flow of deployment. So your lookup field will be deployed but will not work (lists and fields will be empty)
What to do?
1. Either you define all the fields and content types without the lookup fields, define them later in the flow and attach them via a feature receiver to the correct content type
2. Define all the independent content types (content types that does not contain lookup fields) separately, create the lists accordingly and only then define the content type with the lookup fields and create that list as last.
In the end you’ll notice that the first step isn’t the best one, but the easiest one. If you have 80 content types, 70 lists and 400 fields + 30 lookup fields than good luck keeping track…
So the solution has an additional feature with an element “LookupFields” and a feature receiver.
In this feature receiver I’m going to look for the lookup fields in the site columns and add it to the content types. After that I’m calling for a content type update with the attribute true, so that all the changes are being pushed to everything that inherits the content type.
In the next chapter it’s time for some InfoPath talk.