Eval Criteria # 8

Can an attribute value be an embedded content object?

In the last chapter, we discussed attribute values which are references to content objects stored somewhere else in the repository. This is helpful as it means we can compose objects from multiple sources.

A key point of referential attributes is that the other object is independent – it exists somewhere else in the repository, it can be edited and deleted independently, and more than one object can link to it (remember that Bob’s author object in the example was linked to by 300 different article objects).

There’s another way to achieve object composition through a form of “typed attributes,” meaning an attribute value that is, in itself, a wholly contained content object. This value could be called an embedded object.

The key is that the entire object itself is the attribute value, not just an object reference. A complete object is a “captive” inside an attribute. It is not independent, and it cannot be edited or deleted anywhere other than in the context of its owning object. And if the owning object is deleted, the embedded object is deleted too.

The model of typed attribute values. In this case, the Author attribute encapsulates an Author object, which is wholly embedded in the owning type and does not exist independently. Compare this to the corresponding diagram in the prior chapter, where the Author object was independent, and existed outside the bounds of the owning object.

The value of an embedded object is in editorial usability and repository management, since the editorial element will often be an embedded object creation interface specifically for the embedded type. This “sub-interface” might be a modal dialog, collapsible pane, or simple appear as a section inside the main editing interface.

Some editing interfaces might get complicated as the embedded object might be of a type with a very complicated interface itself – in theory, the editing interface of the embedded type could be more complicated than the interface of the owning type.

And what if the embedded object type also has attributes which are embedded objects? What if one of those typed attributes requires a type of the owning object… which also requires a value of the embedded type? Could we have an infinitely nested interface?

If the embedded object’s UI isn’t part of the owner object’s UI, then it’s still likely be clearly referenced which is helpful for editors. Also, the embedded object should always exist in the same editorial lifecycle – when it’s owner is saved, submitted, published, and deleted, the same will occur for the embedded object.

Validation and Repetition

As with referential properties, all other attribute features should still apply:

  1. The attribute value can be validated
  2. The attribute value can be repeated, if the type allows it

Ideally, validation would operate on two levels. There’s an “outer” validation for the type of the owning object, and then an “inner” validation for the type of the embedded object.

The outer validation might enforce that the value is required, and enforce repeating limits (no more than 10, for example). The inner validation would be whatever the type of the embedded object requires.

And either of these validation events could be subject to custom rules. The embedded type (the “inner” validation) might have custom rules to govern its own attributes, and the owning type (the “outer” validation) might have custom rules that reach into the embedded object and inspect its values.

Typed vs. Custom Attributes

In many cases, the line between a typed attribute and a custom attribute can get blurry.

We’ll talk about custom attributes in a later chapter

Say we want a grouped editorial element for image selection, so when we add an Image attribute to a type, the editor is presented with a (1) file selector, (2) alt text input box, (3) caption input box, and (4) image credit input box. We can do this two ways:

  1. Create a custom element that displays all those inputs then serialize them for storage
  2. Create an Image content type to be used as a typed attribute value

One difference is that our Image type might also be available as a standalone object, in addition to being available as an embedded attribute value. So, we might have multiple, independent Image objects in our repository for various reasons – the site logo, for example – and it’s also available as a typed attribute on several content types. That’s not possible for custom attributes, because they’re not fully realized content types, just custom editorial interfaces and methods of serializing values.

Typed attributes can be helpful to describe a content type more fully. A content object might become a collection of complex, discrete, repeating objects, indexed by attribute. This can be accomplished with referential attributes as well, but in situations where the inner object is a wholly contained “subsidiary” of the outer object, embedded objects can ease editing and prevent extraneous objects from cluttering up the repository.

Evaluation Questions

  1. Can an attribute value be an embedded content object?
  2. How is validation applied to a embedded object? Is the embedded object’s internal validation executed?
  3. How are embedded objects edited from the interface?
  4. Are embedded objects versioned with the owning object, or do they have their own versioning sequence?
  5. Are there any limitations on embedded object nesting? If an embedded object also contains embedded objects, how is this handled?
  6. Do events that occur on the owning object also occur on the embedded object? Can the embedded object ever trigger an event?

This is item #16 in a sequence of 35 items.

You can use your left/right arrow keys to navigate