adobe
Support for JSON Value Type in AEM Core Forms Components
Summary
Currently, AEM Core Forms Components largely handle component values in the underlying form model as simple string types. This feature request suggests enhancing the form model and component architecture to natively support JSON objects as component values. This change would allow a single component to represent and manage a complex data structure—like an object with multiple properties or an array of objects—instead of being limited to a single string.
Problem Statement
When building components that naturally group related data points (such as an address block with street, city, state, and zip; a list of items; or a user profile with name, email, and phone), developers currently face a few challenges:
- Creating multiple individual form fields: This results in a flatter form model, more separate form submissions, and makes it more difficult to manage related data as a unified whole.
- Manually serializing/deserializing JSON to/from a string: This requires custom JavaScript on the client-side and potentially custom Sling Model/Java logic on the server-side. This converts complex data structures into a single string for storage, and then parses them back when the form loads. This process adds development overhead, increases the chance of errors, and makes components less "smart" about their own data.
- Relying on custom Sling Models and form submission handlers: While effective, this approach shifts complexity away from the component itself and into backend logic. This makes the component less self-contained and less reusable.
This limitation prevents the creation of truly composable and intelligent form components that can effectively manage their own internal state.
This feature request suggests enhancing the form model and component architecture to natively support JSON objects as component values
In the current model, when a field or panel is defined as type "object," it inherently represents a JSON object. This is already supported natively. For instance, a non-repeatable panel of type "object" will store its value as a JSON object. If you want a field (such as a radio button) to have an object as its value(ie value of "type" property in json is set to object), the custom component at the view layer must handle the rendering of that object—but the model itself already supports this functionality.
In summary, the capability to use JSON objects as component values is already present in the existing architecture. The main requirement is ensuring that custom components properly render and interpret these object values as needed.
Great! Could you show an example of how this works. IE how one defines the field as an object. Currently we parse the json strings for these to get and set the values.
Great! Could you show an example of how this works. IE how one defines the field as an object. Currently we parse the json strings for these to get and set the values.
To configure a component’s value to be stored as a JSON object in forms component, add a type property with the value object to the component’s cq:template node (_cq_template.xml). This ensures the component’s data is structured as a JSON object in the model layer, regardless of the component type.
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0"
jcr:primaryType="nt:unstructured"
jcr:title="Custom text input"
fieldType="text-input"
type="object"/>