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:
These Granite UI form fields are of particular interest as they are used for component dialogs .
For full details about fields, please see the Granite UI documentation .
Use the Granite UI Foundation framework to develop and/or extend Granite components. This has two elements:
- a collection of foundation components
- foundation - modular, composable, layerable, reusable
- components - Sling components
- helpers to aid application development
- 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 by init.jsp .
Please refer to the Granite UI documentation - Field if you want more details.
For examples, see:
- provided by the Code Sample
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:
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.jspIn 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 .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
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 your JS / CSS inside it.Define your JS / CSS inside the clientlib.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.