Many ways to relate Orchard things, part 6: enumerations

Enumeration fields are not exactly relationships, but they implement a very similar scenario. Therefore, it's useful to know about them, so that you can use them when they are relevant.

Enumeration fields are fields that present a set of predefined values, of which one or several can be selected, depending on the field configuration. The values are defined per field, which means that those values can’t be re-used across different content parts. If you have a scenario for re-use of values, then you probably need to use a taxonomy instead.

To add an enumeration field, edit your content type definition and add a new field. If the “Fields” feature is enabled, you’ll be able to add an enumeration field:

Adding an enumeration field

Once the field has been added, we can expand its configuration and add values, one per line, in the “Options” text area:

Adding values to the enumeration. Notice that you can specify whether a value is required, and what the UI will look like for the field, between a drop-down, radio buttons, checkboxes, or a select list. Which UI you choose will also determine whether multiple values will be accepted (radio and drop-down allow only for one value, while checkbox and select allow for multiple values).

In the content item editor for a song, we can now specify what formats the song is available under:An enumeration in the content editor.

On the front-end, the values will be rendered as a label followed by the comma-separated list of values:Front-end enumeration rendering

Of course, this rendering can be overridden with alternate templates in your theme. You could for example display those formats as nice SVG logos.

Let’s recap:

Pros

  1. No code.
  2. Complete tweakable admin UI for any cardinality.
  3. Simple implementation through the Infoset.
  4. As many enumerations as you want per content type.
  5. Can be queried against by projections.
  6. Not a chance of creating select n+1 performance bottlenecks with this.

Cons

  1. Not easy to query against, except using projections.
  2. Can't relate content items.
  3. No reusability of enumerations and their values.

Use cases

You can use enumeration fields where a field is relevant, and where that field should have a discrete set of values that is not used for classification (use taxonomies for this). They are very lightweight, and also somewhat limited.

No Comments