Inheriting dialogs in Adobe CQ5 - aem

I'm trying to implement a component dialog by inheriting a dialog of a base component. I'm having troubles with dialogs when used twice.
BASE COMPONENT
dialog
text (name: "./text/content")
OTHER COMPONENT
dialog
text (inherited from base)
text (inherited from base)
settings
other
The problem with this is that it inherits the name as well and it doesn't look like you can override it. How can I make my jsp print out the two rich-text if they get inherited with the same name? Does CQ5 provide an index so that they can be referenced in the JSPs?

If your plan is to have two rich text areas in the dialog of components that inherit from the base, then you must include two rich text areas with unique names in the base component dialog.
Each input field of a dialog must have a unique name otherwise they will point to the same property path relative to the jcr:content node of the component when used on a page.

As mentioned above, Each input field of a dialog must have a unique name otherwise they will point to the same property path relative to the jcr:content node of the component when used on a page. Here, this will confuse the CRX while recognizing the textArea to be referred and the second one will not be referred.

Related

Hi, If we want to show/hide both tabs and fields in AEM, based on the style selected for a component

Like for my one component there a two styles added , if style one is selected then I have to hide 1 field in cq:dialog and if style 2 is selected then I have to show that field
Is the style mentioned above, is a dropdown within same dialog? If yes, there are numerous examples explaining how to implement Show/Hide of dialog fields. Please check here, here, here, here.
Basically idea is on the dropdown field, add a class cq-dialog-dropdown-showhide and a property cq-dialog-dropdown-showhide-target with a value of class selector unique to component. Then by defining property showhidetargetvalue on the element, selecting the dropdown will show/hide respective properties.
If the style you mentioned is the style system applied using brush icon, it is not OOTB. You ll need to add an authoring clientlib and implement logic to hide specific dialog field based of style system applied.
IMO style system is presentational, only to apply skin to the component. It should not drive business logic of allowing dialog properties. As simplistic, maybe allow authors to enter all allowable fields at dialog and using JS, you may consume / not, the dialog properties.

What is difference between dialog with jcr:primaryType as cq:TabPanel and jcr:primaryType as cq:Dialog

As per the documentation 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. When I open the dialog of text and textimage components both has multiple tabs in it.
So what is the difference between cq:Dialog and cq:TabPanel?
Text Image component Dialog
Text component dialog
cq:dialog and cq:tabPanel are nodeTypes assigned to jcr:primaryType.
As per jcr documentation -
The primary node type of a node usually defines node structure (i.e.,
allowed and required child nodes and properties) related to the
problem domain being modeled.
You can see the details for each nodeType defination in CRX explorer - Node Type Administration - /crx/explorer/nodetypes/index.jsp
The rendering of the node hierarchy is handled by xtype defined for these nodes which can be dialog (/libs/cq/ui/widgets/source/widgets/Dialog.js) or tabPanel (/libs/cq/ui/widgets/source/ext/source/widgets/TabPanel.js)
Each of these scripts are responsible for rendering the node hierarchy to show you the dialog/window/tabpanel
You can read the documentation defined in each of the scripts. Dialog can very well contain tabpanels refer to page's dialog box whose xtype is dialog but the node hierarchy defines tabpanel as well.

Component group not showing in sidekick (Adobe CQ)

Im using adobe CQ 5 and I have created a bunch of components.
For all these components I have set allowedParents to */parsys and I have defined the componentGroup as xyz.
My page contains the parsys component. When I enter the parsys design mode, the list of allowed components does not show the component group xyz.
Please help!
Thanks in advance
Kindly make sure that your components jcr:title is not the same as the component's name. For Eg: if the name of the component is text, then the title should at least be Text and not text. Change it and then check in the design mode, it will list your component group.
Please verify your Jcr:title (text) does not match with your component name. A difference needs to be mentioned i.e. if your component name is Title, then your jcr:title should have title. If the component is still not in sidekick after this, then add this too:
Add cq:editConfig to your component. This will enable you to add your component in sidekick. There is no need to create a dialog.
If your component does not have dialog then child node cq:editConfig enables the component to show in the sidekick. for more please visit http://www.cqtuts.com/cq5/cq5-component.html

Fetch input value of a CQ5 Form Text Component

We want to fetch input value of a CQ5 Textbox Component used multiple times on a single page. We have added components as shown below:-
<cq:include path="lastname" resourcetype="demoproject/components/lastname">
<cq:include path="firstname" resourcetype="demoproject/components/firstname">
Where in firstname and lastname are extended cq5 form text components.
How can we get values of respective fields? We thought of giving unique ID's to each component but since we are using default CQ5 component we are not able to set different ID to each component included in our .jsp page.
Nithalia,
If you will include a component by cq:include then you will be stuck with only one instance of it and will never be able to use it dynamically.
You will have to drag multiple instances of this text component into the Parsys and then will have to configure each of that instance individually. A component when dragged into Parsys is independent of other component because a different node is created each time you drag it. While if you will include it only a single node will be created and hence editing can be made but only once.
If you want to do some research, drag the text component multiple times on Geomartixx site and configure them individually and see the nodes that will be created under the /content path.

AEM/CQ5 how to share component values?

I want to have a header component that is shared across multiple page rendering components. The header component has a text label. How do I make the value of this text label available to all page components.
Do I have to make the path in the <cq:include> to a common format?
Design mode, if properly understood, can work quite well. However, it doesn't replicate content in the same manner as page activation, and thus can be confusing for your authors. Also, the sharing model is limited to the exact page type - which may or may not be the granularity you desire.
From CQ5's Best Practices (https://dev.day.com/docs/en/cq/current/developing/developing_guidelines_bestpractices.html), they strongly encourage the paragraph system (iparsys to inherit/share). iparsys named the same can be shared across different page templates (while design mode will only apply to a single template type).
I can archive that by creating a design dialog that is similar to dialog (http://dev.day.com/docs/en/cq/5-6/developing/components.html#Dialogs) under the header component. You add the text label field to design dialog. And to enter value for the field, you switch the page to the design mode and click on Edit button on the top of the component. The entered value will be available to all pages that contain the header component.
Note: design dialog will be named as design_dialog
This functionality is now offered in ACS AEM Commons as Shared Component Properties - http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html
Supports standard content activation and internationalization (values stored below the homepage) and anything else you would expect from content.
If the component is baked in the template(i,e page rendering component), yes you can make the <cq:include> path attribute to point to some common place where the data for this is stored and all the pages irrespective of , type of the template can get the values configured.
You can create header component and then include it using <cq:include> in base template/page. This base template/page will be inherited by all other templates. This way the header once configured in base page is availble through out different templates/page components.
If the goal is to share "across multiple page rendering components" the design dialog will only help if the page share the same rendering component.
If you want to have the header component displayed in a page and all its subpages, then you should use iparsys.
If you just want to reuse the properties of that header component, then it needs to have a fixed path (cq:include in a page component) and then you can reference the properties you need in other page rendering components. I would not suggest that approach since it breaks the idea of having a component. Everything becomes tightly coupled.
What you could also do is save those properties at the page level (some top parent page) and then use InheritanceValueMap in the subpages to read those properties.