When we create a new page in CQ5 'siteadmin' , we get two fields to fill up ("Name" and "Title").
Could there be any way to add more fields here (Say, "Description") which the authors can fill up and it will be saved as a JCR property of the page in CRX ?
Any ideas/solutions will be welcome. I can't think of any.
You want to add custom page properties. From the linked knowledge base article:
(1) Copy /libs/foundation/components/page/dialog node to your template's
component that you want to add dialog properties to.
(2) Add fields to the dialog
Example:
If you had a page component /apps/<myapp>/components/pages/contentpage
that has sling:resourceSuperType=/libs/foundation/components/page then
you would copy /libs/foundation/components/page/dialog to
/apps/<myapp>/components/pages/contentpage/ to make an overlaid dialog
Related
I have a Sightly component with a (JavaScript) UseAPI model in an Adobe AEM/CQ site.
In the model, I have a variable that is calculated when the component loads and is not stored in the JCR (let's say it's a random string).
When an author opens the Granite/Touch UI dialog, there is a custom Granite UI component rendered with a JSP. The JSP has access to the scope of the component in the JCR, but as far as I can tell it does not have access to properties returned by the JavaScript model when rendering the component.
How can I pass/store this 'random string' variable from the Sightly/JavaScript UseAPI so that it can be accessed by the JSP of the dialog?
The variable is context-sensitive so I wouldn't want to store it in a permanent location such as the JCR. A good example may be a unique identifier for an external web service, that is unique for that particular rendering of the component.
I can think of a couple of approaches, with varying applicability:
Dialog field emptyText property: This just shows grayed out/hinting text and does NOT set any content that can possibly be rendered.
Dialog field defaultValue property: This looks very tempting, but I don't recall having success with it.
Dialog event handlers: (adding JavaScript inside the XML of a dialog definition). I am not a fan of this approach since it isn't obvious how/where the magic happens. But it is possible to update/populate fields on dialog load or dialog save.
Component cq:template: just like a page template, you can provide default content when dragging a component into a parsys. This doesn't work for components cq:included into the page/component. Also, it doesn't prevent the author from deleting the value altogether unless you add event handlers on the dialog.
Create a component model. The model can provide default content/values if properties are missing or not populated. The drawback is authors may not understand where magic values are coming from if dialog fields are blank. Once I worked around this by creating a tag that would use authored values, then fall back to dialog emptyText properties, then to possible template values to "fill in" the content. This takes some initial developer effort, but provided hints to the authors if the content was missing, or the component was included instead of dragged on, ...YMMV.
However, none of these may work for you if the value is "context sensitive" and has to be calculated somewhere/somehow. But if it is computed, then it probably shouldn't be authored.
I'm trying to create a component that I can drag into a parsys component, but for some reason it doesn't show up in the list of available components (see images below). I'm pretty new to AEM, so if I sound ignorant, I probably am (edits to this question are welcome).
The first and the foremost requirement for your component to be draggable is to have either a dialog or design_dialog.
Second, it shouldn't be part of the component group .hidden. It is fine if it doesn't have a componentGroup property at all, you can find it under NO GROUP DEFINED.
Set the allowedParents property of type String[] to */parsys.
And finally make sure that the jcr:title is different from the name of your component. They shouldn't be the same. For Eg: If the name of the component is text then the title should at least be Text.
I haven't worked in the touchUI, but for sidekick this holds good. So I guess it should work for your case too.
First: Make sure you have a dialog defined.
Second: Ensure that there is a componentGroup defined that doesn't start with a period. ANY group name that starts with a period will hide the component.
Third: Make sure the component is enabled with design mode.
AEM Mastery blog post about getting a component to show in the sidekick
My Requirement is to have a global header and footer with author able properties.
So if we update the properties on one page it should be reflected across all pages.
What is the best approach to achieve this in CQ5.
ACS AEM Commons now supports this functionality without use of an iparsys - Shared Component Properties (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Configure your menu with Shared and/or Global properties and you can simply template it directly onto all of your pages (no iparsys required). You can then edit the header/footer from any page on the site and it will by updated on all pages.
Unlike using design dialogs, Shared Component Properties supports standard content activation and internationalization (values stored below the homepage) and anything else you would expect from content.
If all of your pages site under a hierarchy, you could use an Inherited Paragraph System (iparsys). This is from an old version of the documentation, but is still a good intro:
The inherited paragraph system is a paragraph system that also allows
you to inherit the created paragraphs from the parent. You add
paragraphs to iparsys at for example, /content/geometrixx/en/products
and as result, all the subpages of products that also have iparsys
with the same name inherit the created paragraphs from the parent. On
each level, you can add more paragraphs, which are then inherited by
the children pages. You can also cancel paragraph inheritance at a
level at any time.
While not quite what you're describing in the original post (edit anywhere) it will allow you to edit the content once (at the parent page) and inherit the changes everywhere.
Traditionally you could create the components and swap the dialogs out for design dialogs. Basically you would rename your component dialog to design_dialog.
What this will do is save the changes you make to this object to a design path under etc. You can set a design path for site by going to the top level parent and setting a designPath property.
So node structure might look something like
parentNode
- #prop designPath = "designs/myapplication"
childNode1
childNode2
etc...
Any component using a design_dialog on the parentNode or its children nodes will get their information from the designPath. If you do not set a design path, the infomration is saved under etc/designs/default (or defaults, not sure, going off the top of my head).
There are some alternatives to this:
What our team did was in our siteHeader component we use http://dev.day.com/docs/en/cq/current/javadoc/com/day/cq/commons/inherit/InheritanceValueMap.html (inheritancevalue map) instead of the regular value map. The inherited value map will traverse the tree up looking for items from it's parents. This is a great source for learning how to use valuemap instead of just the default properties object:
http://experiencedelivers.adobe.com/cemblog/en/experiencedelivers/2013/02/valuemap-and-his-friend.html
This does get complicated with larger sites, and you'll have to do a lot of customization to get the system working the way you want, but it's an option if you don't want to have to manually set designPaths for every new site your authors create.
Alternatively, if you do like the idea of using designPaths and design_dialogs, you can always hook into the page creation workflow and have the page component add a designPath property on creation (this is a lot easier said than done though).
hope that helps
My question is very basic . I am creating a new template and in that template, I will have a concrete structure using DIV elements. But in almost 7-8 if the DIV's, I need the data to be entered by the user.
What component/line of code I can use to have all those 7-8 DIV's editable and customizable by the page creator ?
I tried multiple paragraphs with :
<cq:include path="par" resourceType="foundation/components/parsys"/>
But only the top one appears on the page. !!
For having multiple paragraph just rename the path value in the cq:include tag. also check here
I am creating a new tab in dotnetnuke but I also want to add tags for my tab (pages). I don't know I how to accomplish this task. I have use taxonomy class but in that class we can define tags but I want to add tags programatically for my page when I am adding a new page (tab).
Try using a DotNetNuke.Entities.Content.ContentController to get a ContentItem instance based on the tab's ContentItemId. You can then add to the Terms list and use the ContentController to update the content item.