Components and their structure

Component definitions

As already mentioned, the definition of a component can be broken down into:

  • CQ components are based on Sling

  • CQ WCM components are located under /libs/foundation/components

  • site specific components are located under /apps/<sitename>/components

  • CQ WCM has the page component; this is a particular type of resource which is important for content management.

  • CQ5 standard components are defined as cq:Component and have the elements:

    • a list of jcr properties; these are variable and some may be optional though the basic structure of a component node, its properties and subnodes are defined by the cq:Component definition

    • the dialog defines the interface allowing the user to configure the component

    • the dialog (of type cq:Dialog) and cq:editConfig (of type cq:EditConfig) must both be defined as otherwise the component will not appear

    • resources: define static elements used by the component

    • scripts are used to implement the behavior of the resulting instance of the component

    • thumbnail: image to be shown if this component is listed within the paragraph system

If we take the text component, we can see these elements:

Properties of particular interest include:

  • jcr:title - title of the component; for example, appears in the component list within sidekick

  • jcr:description - description for the component; again appears in the component list within sidekick

  • allowedChildren - components which are allowed as children

  • allowedParents - components which can be specified as parents

  • icon.png - graphics file to be used as an icon for the component

  • thumbnail.png - graphics file to be used as a thumbnail for the component

Child nodes of particular interest include:

  • cq:editConfig (cq:EditConfig) - this controls visual aspects; for example, it can define the appearance of a bar or widget, or can add customized controls

  • cq:childEditConfig(cq:EditConfig) - this controls the visual aspects for child components that do not have their own definitions

  • dialog (nt:unstructured) - defines the dialog for editing content of this component

  • design_dialog (nt:unstructured) - specifies the design editing options for this component

Dialogs

Dialogs are a key element of your component as they provide an interface for authors to configure and provide input to that component.

Depending on the complexity of the component your dialog may need one or more tabs - to keep the dialog short and to sort the input fields.

For example, you can create the dialog as cq:Dialog, which will provide a single tab - as in the text component, or if you need multiple tabs, as with the textimage component, the dialog can be defined as cq:TabPanel:

Within a dialog, a cq:WidgetCollection (items) is used to provide a base for either input fields (cq:Widget) or further tabs (cq:Widget). This hierarchy can be extended.

Component definitions and the content they create

If we create an instance of the Text paragraph (as above) on the <content-path>/Test.hml page:

then we can see the structure of the content created within the repository:

In particular, if you look at the title:

  • the definition of /libs/foundation/components/text/dialog/items/title has the property name=./jcr:title

  • within the content, this generates the property jcr:title holding the input Test Title.

The properties defined are dependent on the individual definitions, which although they can be more complex than above, follow the same basic principles.

Component Hierarchy and Inheritance

Components within CQ are subject to 3 different hierarchies:

  • Resource Type Hierarchy:

    This is used to extend components using the property sling:resourceSuperType. This enables the component to inherit; for example a text component will inherit various attributes from the standard component.

    • scripts (resolved by Sling)

    • dialogs

    • descriptions (including thumbnail images, icons, etc)

  • Container Hierarchy :

    This is used to populate configuration settings to the child component and is most commonly used in a parsys scenario.

    For example, configuration settings for the edit bar buttons, control set layout (editbars, rollover), dialog layout (inline, floating) can be defined on the parent component and propagated to the child components.

    Configuration settings (related to edit functionality) in cq:editConfig and cq:childEditConfig are propagated.

  • Include Hierarchy

    This is imposed at runtime by the sequence of includes.

    This hierarchy is used by the Designer, which in turn acts as the base for various design aspects of the rendering; including layout information, css information, the available components in a parsys among others.

Summary

The following summary applies for every component.

Summary:

Location: /apps/<myapp>/components

Root Node:

  • <mycomponent> (cq:Component) - Hierarchy node of the component.

Vital Properties:

  • jcr:title - Component title; for example, used as a label when the component is listed within the sidekick.

  • jcr:description - Component description; for example, also shown in the component list of the sidekick.

  • allowedChildren - Specifies the allowed child components.

  • allowedParents - Specifies the allowed parent components.

  • icon.png/thumbnail.png - Icon & thumbnail for this component.

Vital Child Nodes:

  • cq:editConfig (cq:EditConfig) - Controls author UI aspects; for example, bar or widget appearance, adds custom controls.

  • cq:childEditConfig (cq:EditConfig) - Controls author UI aspects for child components that do not define their own cq:editConfig.

  • dialog (cq:Dialog) - Content editing dialog for this component.

  • design_dialog (cq:Dialog) - Design editing for this component.