Eval Criteria # 10

Can custom attribute types be created?

Contents

The number of built-in attribute types differs by system, but eventually you might find yourself needing more than what’s offered to fill in gaps. Some systems offer the ability to develop completely custom attribute types.

You might need this for several reasons:

A Custom Attribute Example

Here’s an extended example to demonstrate multiple reasons why a custom attribute might be necessary.

Many systems provide color pickers, but what if you had several unique requirements around color selection? A simple RGB color is three numbers, each from 0 to 255. However, let’s complicate this with the following requirements:

What the described custom attribute type might look like.

Clearly, this is not supported as a built-in attribute type by any existing CMS. The interface and logic around it will have to be built as a custom attribute type.

As we discussed earlier, an attribute is actually a container of several things. For this particular situation, we’d likely need to develop several different units of code:

API Support for Custom Attributes

API support for custom attributes varies greatly. In a well-architected system, the built-in attributes would use an API framework that’s designed to be extended, meaning all attributes are “custom” to the extent that they’re built using the same framework. This is also helpful as the built-in attribute types provide a pattern on which to base your custom attribute types.

In addition to providing reference implementations, a common framework often allows custom attribute types to inherit from built-in attribute types.

For example, if you need some type-ahead search suggestions in a simple text box, it might be helpful to start with a textbox attribute type and extend it by just adding the required JavaScript code, without having to re-implement the entire “attribute bundle,” as described above. In many cases, you’ll find that your custom attribute is just a built-in attribute with a few selected changes.

Another assumption is that once developed, the custom attribute type is added to the “palette” of attribute types available to use in other content types. A system would limit itself considerably if an attribute type could only be developed to service a specific attribute assignment, and would have to be re-implemented for usage in other types.

One school of thought says the perfect CMS wouldn’t need custom attribute type development because all necessary types would be provided as built-in. However, this would likely require an attribute type range that would be unreasonably expansive and unwieldy. The next best option, then, is a well-thought out architecture for custom types, and the ability to inherit from and deeply customize existing types.

Evaluation Questions

  1. Can custom attribute types be created?
  2. By what method are attribute types created?
  3. Can built-in attribute types be extended with extra functionality?
  4. How are the client-side editorial interfaces created? What limitations exist on custom HTML, JavaScript, and CSS? Are there standard frameworks (React, Angular, JQuery, etc.) that will need to be used?

This is item #18 in a sequence of 34 items.

You can use your left/right arrow keys or swipe left/right to navigate