This conversation has been locked due to inactivity. Please create a new post.
This conversation has been locked due to inactivity. Please create a new post.
.somewhere i have seen this kind of implementaion without using design dialog and all how they are making global things
============================================================================================
I have queries how it is working:
1) In apps cretaed a component apps/.../siteconfigcomp and created dialog (like footer image footer title and header image and header title everything globally whichever i needed )and one .html file (which i m not sure wat they are doing in that )
made a siteconfig.html page inside etc/design/myproject/siteconfig.html and used slingresourcetype as apps/.../siteconfigcomp
now if we open etc/design/myproject/siteconfig.html we get all dailog field one by one like a page and save button like dialog only and author can fill the values and save it . and it will be saved etc/design/myproject/siteconfig/jcr:content.
Now if any page in /content wants top use that footer image header image header text or title (any global values ) we can use
because page inside /content/rootnode will have cq:design path like etc/design/myproject/siteconfig
note :slingResourceSupertype : wcm/core/components/designer is this ...for component..........-------->>> apps/.../siteconfigcomp
now question is :
How that etc/design/myproject/siteconfig.html is looking like a page rather a dialog which comes when we congfigure any component in desgin mode . here dialog is stable and coming like form or page . ?
And please explain if this is any standard approach for header and footer values .
Views
Replies
Total Likes
This is not the default way to using the design dialogs. It's a customization by itself (which can be done) but which requires additional work to integrate it.
The problem: If you have more than 1 site which should have the same design ( = clientlibs) but different header/footer it's getting hard, not to say: impossible. Because it mixes design (in the way CQ5/AEM is using it) with content.
Thus you should store header and footer information (which is displayed and which should be customizable by authors) in /content, and the design somewhere else.
And with editable templates, Context-Aware Configuration and the repository restructuring of AEM 6.4 (and later), I would assume that new features do no longer use /etc/designs. Which is also something you should think of :-)
Jörg
Views
Replies
Total Likes
here cq:dialog has been used they have not used desgin:dialog......and header and footer informations like title and images are being stored in etc/design/myproject/siteconfig/jcr:content.
and now I can use thses information in my Header component easily .
@Inject
Designer currentDesign;
and then currentDesign.getDesign(currentPage).getContentResource().getChild("node-name of etc/design/myproject/siteconfig/jcr:content. lke footerTitle")
now question is :
How that etc/design/myproject/siteconfig.html is looking like a page rather a dialog which comes when we congfigure any component in desgin mode . here dialog is stable and coming like any form page or like a dialog page . ?
Views
Replies
Total Likes
As per my understanding, content fragments would be good option to use in case you wish to have global header n footer. A content fragment could be managed from a single source and changes would be easily pushed to all the pages without much effort.
Refer:
Adobe Experience Manager Help | Using Content Fragments in AEM
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies