If we give cq:includeClientLib inside my component jsp and if we drag and drop the component twice on that page, will the clientlib gets loaded/included twice?
what will be the case if we do in Sightly way (data-sly-call="${clientlib.all # categories='somecategory'}") ?
And also what is the suggested method of including client libs, either create a clientlib specific to the component and load only for that component or include all the CSS and JS at a common clientlib and use it across?
No, the clientlib is only included once for a category.
This is by design as the HTL (and respective JSP tag) are evaluated during runtime and the processor keeps a map of categories that have already been included and does not include them again.
As #i.net mentioned, each category will only be included once. To answer your follow up question about the suggested method..
The best practice seems to be to define a client library for each component, which is then embedded into a "global" client library. That global client library will then be included within your page template.
/etc/designs/acme/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
The reason the global client library is located under /etc/designs is to prevent exposing /apps to the public. However, in AEM 6.3, you could make use of the allowProxy property to serve the code at /etc.designs/. This would then look like this:
/apps/acme/clientlibs/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
allowProxy=true
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
Adobe recently released a good tutorial of more recent best practices around client library structure: https://helpx.adobe.com/experience-manager/kt/sites/using/getting-started-wknd-tutorial-develop/part3.html
Related
I have Liferay 7.2
I want to customize the html of the layout of the widget Documents AND Media
I tried to create a hook to document and media but it seems that is not the right way.
How can i do that?
First, the fact that you're talking about a hook tells me that you're coming from Liferay 6 or earlier. Forget the old module types ("war-style modules"), embrace the new "jar-style modules" or "OSGi modules", which leverage the OSGi methods and mechanisms in the foundation. The new module type that comes closest to the functionality of hooks would be a "module fragment".
Alternatively, if you want to create one module that overrides the JSPs of more than one other module (or overrides JSPs as a side effect to its main purpose), you may want to look into "JSP Bags".
Still, both methods are discouraged and should be taken as a last resort, according to Liferay's "Introduction to Customizing JSPs".
The preferred method would be to use Dynamic Includes (albeit they only work if the target portlet has been written to include inclusion points) or Portlet Filters (which basically allow you to programmatically edit the request to and response from the standard Portlet classes and JSPs).
Still, if you're aiming to replace most of the JSPs of the standard document and media widget (keep in mind: Widgets are still Portlets, they just have been renamed in the frontend), a module fragment still seems to the best way forward.
To identify the correct module, here are the necessary steps. I'll show it using the DLAdmin portlet from the control panel as an example:
Identify the portlet you want to edit: Look into the HTML using the DOM inspector of your browser. Look for section tags with IDs like <section class="portlet" id="portlet_com_liferay_document_library_web_portlet_DLAdminPortlet"> around the area of interest.
Now translate that ID into a package path with portlet class: com.liferay.document.library.web.portlet.DLAdminPortlet. Search for that class in the Liferay github repository. (Go there, press T, enter the class name, find its Java class source file. In case of multiple hits, you need to check the package path, too.)
Once you opened the source file, go back up in the file tree to the parent folder of the src folder. There's a bnd.bnd file. Take a look into it, it will tell you the Bundle-SymbolicName.
Use the Liferay IDE or Blade CLI (depending on your development environment) to create a module fragment for the module identified by the Bundle-SymbolicName.
Is it possible to conditionally include different clientlibs based on the user agent of the browser?
IE
<sly data-sly-use.clientLib="/libs/granite/sightly/templates/clientlib.html"
data-sly-call="${clientlib.js # categories='a'}"/>
Modern Browsers
<sly data-sly-use.clientLib="/libs/granite/sightly/templates/clientlib.html"
data-sly-call="${clientlib.js # categories='b'}"/>
AEM version: 6.3
If not, what are the other alternatives to achieve the same?
Note: I tried to get this check done in a sling rewriter server side but the problem is, with the dispatcher on, it will only hit AEM for the furst time and cache the html, any subsequent hit will not invoke any server side logic to render it. Hence, it has to be done client side IMO
For this you have to write custom clientlibs templates as described here : https://github.com/nateyolles/aem-clientlib-async.
And then in the WCMUse class you can check user agent and include clientlibs accordingly.
First of all, as you already pointed out correctly, you need asolution that works with the dispatcher cache. So Sightly is not an option.
Then, regarding the fact, that most AEM templates have paragraph systems with multiple possible components to be added to a page on the one hand and AEM clientlibs are build on a template level (and not on page level) you end up with a clientlib holding lots of unused JS and CSS most of the time, since you have to cover all the possible options of components used in your page and paragraph system.
With that in mind, clientlibs might not be a good option to be used after all.
Having static CSS and JS files in your AEM repo and referencing them client side based on a JS snippet will do the trick and - in most cases - you will not buy any side effects with that approach.
You can either:
Wrap your clientlibs with conditional comments: https://stackoverflow.com/a/11703767
Create a Use-Object that check the User-Agent header and exposes a method isIE that you can use to conditionally include the clientlibs with data-sly-test. Alternatively your Use-Object could just return the proper categiers based on user agent so you can have only one clientlib call.
You could use the <script module> and <script nomodule> to achieve that. The first one is ignored by older browsers and the second one by the modern ones. Similar to Vue's Modern Mode. Check: https://cli.vuejs.org/guide/browser-compatibility.html#modern-mode
More likely you would need some back-end to create your custom clientlib template.
The publisher instance has the following javascript files included:
/etc/clientlibs/granite/jquery.min.js
/etc/clientlibs/granite/utils.min.js
/etc/clientlibs/granite/jquery/granite.min.js
/etc/clientlibs/foundation/main.min.js
/etc/clientlibs/granite/jquery/granite/csrf.min.js
It would be best to exclude them for performance and also the fact that I am using jQuery 2.0 as my part of AEM site.
These scripts(not including the csrf.min.js) are part of the category cq.foundation-main. You can use this utility for checking this.
http://localhost:4502/libs/granite/ui/content/dumplibs.test.html?categories=cq.foundation-main
If you create your page template components by extending the OOTB wcm/foundation/components/page (assuming you use sightly), AEM will add these scripts in the head section. More specifically these are included in headlibs.html file present under the OOTB page component.
To overcome this, you can override this file in your component, and either comment this below line or include it conditionally only when wcmmode is edit.
<sly data-sly-test="${wcmmode.edit}" data-sly-call="${clientLib.all # categories='cq.foundation-main'}" />
For JSP based components (foundation/components/page), the same thing is done in headlibs.jsp.
By the way, you wouldn't want to remove the CSRF JS. It's AEM's solution to counter CSRF issues.
What you see is the clientcontext related js'es
The script that loads the given js'es is as below (or sth similiar)
<cq:include path="clientcontext" resourceType="cq/personalization/components/clientcontext"/>
either you exclude it completely for publish (wcmMode=disabled) which would probably break sth related to analytics on your publish, or change the include to some overwrite of the clientcontext component that you'd develop.
If you however don't use any native Adobe integration you should be safe just with excluding the thing.
Are there any validators for Eclipse that checks that internal links between JSF web pages in the same project refers to existing pages?
I realise this is impossible to do in more complex cases, but it should be possible to do in the standard case.
One way to achieve something similar is to create Java constants for all page source files names (for example as properties in an app scoped bean) and reference them from EL, because EL validation checks those. But to do this you have to manually add all the file names which is cumbersome.
I'm getting into Google Web Toolkit, and am a little confused about the Entry Points in GWT. Google's docs say:
If you have multiple EntryPoints (the interface that defines onModuleLoad()) within a module, they will all be called in sequence as soon as that module (and the outer document) is ready.
If you are loading multiple GWT modules within the same page, each module's EntryPoint will be called as soon as both that module and the outer document is ready. Two modules' EntryPoints are not guaranteed to fire at the same time, or in the same order in which their selection scripts were specified in the host page.
So does each page in your website need an Entry Point defined for it?
Do you only really NEED an entry point when you have javascript generated based on your Java classes?
Are you able to combine multiple auto-generated-js definitions into a single *.gwt.xml file?
EDIT: Link to quoted source: http://code.google.com/webtoolkit/doc/1.6/DevGuideOrganizingProjects.html
Thanks!
The most straightforward way to make a GWT app is to have a single page for the entire application, and a single top-level module (defined in a .gwt.xml file). Each module has a single EntryPoint class. Then all of your different "pages" are sub-sections of the same page, ideally using GWT's history mechanism to keep track of state changes that in a non-AJAX web app would be new pages. So if you set things up this way you'll need one EntryPoint for your whole app.
The bit of the docs that you quoted (link?) discuss what I think is an advanced use case, where you've got more than one module that you're loading on a single page.
there is one options, U can create maven project with sub projects, means U can create multi entrypoint,
each entry point have own html. See more details