Creating custom field types is simpler with eZ Platform 3

At the heart of eZ Platform lies the content engine. Its most defining feature is the flexible content model built from field types. By default, it ships with a number of field types that cover a lot of use cases, but it is also possible to create custom field types for specific needs.

One of our targets for eZ Platform v3.0 was to improve the developer experience. This resulted in generic enhancements to APIs through convenience methods for loading commonly used data, etc. Another big improvement for field types was the introduction of the Generic Field Type.

The Generic Field Type was created to accelerate development of custom field types. It is a base class for developers to extend when building their own field types. This reduces the amount of code and configuration needed, but it is opinionated on things like using our default storage mechanism. For many cases it helps focus on the problem rather than writing boilerplate code.

Less code needed to meet common requirements

Many custom field types store a few distinct values and provide a custom UI widget for editing. This is a common pattern for integration field types, or when you want to store two highly related values in a single field (e.g. model number and revision). For this, the standard storage model works and scales very well. Especially when indexed by our integrated search engine.

For storing complex datasets with relations between a number of objects, the standard storage mechanism is not ideal. For these cases eZ Platform provides mechanism to store field content as external data. Most often external data is stored in custom database tables outside of our standard schema, this adds overhead when creating and maintaining the custom field type.

For example, we use the custom storage method in eZ Platform Enterprise Edition to store data in field types used by the Page Builder and the Form Builder features. For these, the overhead of having a few extra classes in your code base is negligible compared to the complexity as a whole.

So when should you go with the Generic Field Type? As a rule of thumb, if you feel the majority of functionality in your field type lies in integration or UI, save yourself some time and start with it. If storage becomes a limiting factor, you can refactor your field type to lower level APIs later.

The core Field Type API has not changed

It's important to note that the Generic Field Type is built on top of the Field Type APIs. They continue to work as they did before, so any existing field types should not break. In fact, we did not modify the simple core field types like Integer or TextBlock to use the new base class.

While we did not fix something that wasn't broken, if you've got a custom field type you plan to migrate from eZ Platform v2.5 LTS to v3.x you should verify that they are wholly compatible with the v3 core APIs (see list of deprecations). As per semantic versioning we guarantee the stability of APIs for the lifecycle of a major version (v3.x). Breaking changes are not allowed before v4.0.

If you're starting a new project implementation today where you will need to create custom field types, I would recommend going for eZ Platform v3.1 and using the Generic Field Type if it suits your use case. If followed by an upgrade to v3.x LTS (to be released later this year) you will gain long term support soon and use the latest features for development. The best of both worlds.

Learn how to create custom field types more conveniently from the documentation on creating a custom Field Type. There is also a step-by-step guide to creating a 2D point field type available.