Creating a New Granite UI Field Component creating-a-new-granite-ui-field-component
Granite UI provides a range of components designed to be used in forms; these are called fields in the Granite UI vocabulary. The standard Granite form components are available under:
/libs/granite/ui/components/foundation/form/*
Use the Granite UI Foundation framework to develop and/or extend Granite components. This has two elements:
-
server-side:
-
a collection of foundation components
- foundation - modular, composable, layerable, reusable
- components - Sling components
-
helpers to aid application development
-
-
client-side:
- a collection of clientlibs providing some vocabulary (i.e. extension of the HTML language) to achieve generic interaction patterns through an Hypermedia-driven UI
The generic Granite UI component field
is composed of two files of interest:
init.jsp
: handles the generic processing; labelling, description, and provides form value you will need when rendering your field.render.jsp
: this is where the actual rendering of the field is performed and needs to be overridden for your custom field; is included byinit.jsp
.
Please refer to the Granite UI documentation - Field if you want more details.
For examples, see:
-
cqgems/customizingfield/components/colorpicker
- provided by the Code Sample
-
granite/ui/components/foundation/form
/libs/granite/ui/components/foundation/form
directoryCreating the server-side script for the component 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:code language-none // 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
.note note NOTE 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.
Creating the client-library for the component creating-the-client-library-for-the-component
To add specific client-side behavior to your component:
-
Create a clientlib of category
cq.authoring.dialog
. -
Create a clientlib of category
cq.authoring.dialog
and define yourJS
/CSS
inside it.Define your
JS
/CSS
inside the clientlib.note note NOTE 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.