As this mechanism uses JSP, i18n and XSS are not given out-of-the-box. This means that you will need to internationalize and escape your Strings. The following directoriy contains the generic fields from a standard instance, you can use these as a reference:

/libs/granite/ui/components/foundation/form directory

Creating the server-side script for the component

Your customized field should only override the render.jsp script, where you provide the markup for your component. You can consider the JSP (i.e. the rendering script) as a wrapper for your markup.

Create a new component that uses the sling:resourceSuperType property to inherit from:

/libs/granite/ui/components/foundation/form/field

Override the script:

render.jsp

In this script, you need to generate the hypermedia markup (i.e. enriched markup, containing the hypermedia affordance) so that the client knows how to interact with the generated element. This should follow the Granite UI server-side style of coding.

When customizing, the only contract that you must fulfill is to read the form value (initialized in init.jsp) from the request using:

// Delivers the value of the field (read from the content)
ValueMap vm = (ValueMap) request.getAttribute(Field.class.getName());
vm.get("value, String.class");

For more details, please refer to the implementation of out-ot-the-box Granite UI fields; for example, /libs/granite/ui/components/foundation/form/textfield.

Merk:

At the moment, JSP is the preferred scripting method, as passing information from one component to another (which is quite frequent in the context of form/fields) is not easily achieved in HTL.

At the moment, the Granite UI does not provide any out-of-the-box listeners or hooks that you can use directly to add JS behavior. So, to add additional JS behavior to your component, you have to implement a JS hook to a custom class that you then assign to your component during the markup generation.