Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Overlaying clientlibs in AEM 6.2 is successfully overlaying BUT ALSO implementing seperately, essentially calling the script twice

Avatar

Level 2

Hello, I'm having trouble predicting the behavior of overriding a (Javascript) client library. This is what's happening:

etc/clientlibs/foo.js console.log("Hello from etc"); libs/clientlibs/foo.js console.log("Hello from libs");

Expected statement printed to the console:

Hello from etc

Actual printed statement:

Hello from etc Hello from etc

When I investigate, both statements are printed from foo.js BUT the first is from etc and the second is from libs. Sometimes clearing the cache results in

Hello from etc Hello from libs

but that is also not the desired output. And sometimes the printed statement will be

Hello from libs

failing to override libs/clientlibs/foo.js or even calling etc/clientlibs/foo.js

to be more concrete, I'm trying to override 

/libs/granite/ui/components/coral/foundation/clientlibs/foundation

I've tried modifying the categories from 

granite.ui.coral.foundation

to 

mysite.granite.ui.coral.foundation

but I don't know what that does, and it seems to prevent the overlaying. I don't have a good understanding of how (specifically by what function) the foo.js script is built either. (I do understand that the js.txt, which lists the JS files to combine, are inside the clientlibs/foo directory which makes the combined foo.js, but I don't know where in AEM this being constructed.)

My question is, how do I make this work? :)

1 Accepted Solution

Avatar

Correct answer by
Level 4

From what I know, and please anyone correct me if I am wrong, there is no overlaying of clientlibs.

Clientlibs are registered globally via a 'Category Name'.

Categorys are then called on to be placed into a page.

If you create a custom javascript, and add it to a category that already exists, say 'cq.authoring.dialog' then when that clientlib is called, that code gets called as well. If you create a file that already exists in the clientlib, it doesn't replace that file during clientlib resolution, it just gets stacked onto it.

There is a tool that might help explain this concept:
http://localhost:4502/libs/granite/ui/content/dumplibs.html

The hard part about a single category that are being created from multiple areas, is the script resolution order.

Another link that might help, as I believe they go into validation inside of AEM dialogs, is this AEM Gem of Customizing Dialogs:
https://docs.adobe.com/ddc/en/gems/customizing-dialog-fields-in-touch-ui.html

Good Luck

View solution in original post

7 Replies

Avatar

Level 7

I think that what you want to do is not correct. You want override totally foundation clientlib, why?

If you want to modify some behaviour you can do this just extending the clientlib, and this is performed just putting in your clientlib the same categories of foundation clientlib.

Avatar

Level 2

Thank you, could you explain further?

What I'm trying to do is extend the coral validation scripts to add my own custom form validation.

/libs/granite/ui/components/coral/foundation/clientlibs/foundation/js/validation/validator/my-validation.js

It seems as simple as adding a script to that location, but I know that I don't want to do that directly. While I can add my-validation.js to my own clientlibs, it's missing dependencies that are built into the foundation.js. I don't know how to properly extend the validator, and, on a larger scale, I suppose I don't understand how client-side libraries are built and maintained. 

I tried adding granit.ui.coral.foundation to the categories but now the script isn't being built at all. 

http://stackoverflow.com/questions/13052261/what-is-the-difference-between-embed-and-dependencies-fo...

This kind of implies to me that "categories" is a reference name and "dependencies" are asked to be loaded in to make that script complete? 

I'm not sure what the proper way to do what I'm trying to do would be.

Avatar

Level 10

In your target ClientLibs that you are referencing from the component -- make sure there is only 1 JS Script. So if you want to call this ClientLib

etc/clientlibs

Make sure it has a unique categories property name (ie - myscript) and reference that in your component. 

Avatar

Level 7

Ok,

Inside AEM all the js files that are included in the js.txt are included in one single clientlib. So your validator (even if is inside a folder) is part of the clientlib foundation because the folder validation is just only an nt:folder and not a clientlib.

So is not possible in your case to override only validator.js because is part of a clientlib which contains all the foundations javascript.

Please explain me which change you need to do in the foundation and i can try to suggest you a solution.

Avatar

Correct answer by
Level 4

From what I know, and please anyone correct me if I am wrong, there is no overlaying of clientlibs.

Clientlibs are registered globally via a 'Category Name'.

Categorys are then called on to be placed into a page.

If you create a custom javascript, and add it to a category that already exists, say 'cq.authoring.dialog' then when that clientlib is called, that code gets called as well. If you create a file that already exists in the clientlib, it doesn't replace that file during clientlib resolution, it just gets stacked onto it.

There is a tool that might help explain this concept:
http://localhost:4502/libs/granite/ui/content/dumplibs.html

The hard part about a single category that are being created from multiple areas, is the script resolution order.

Another link that might help, as I believe they go into validation inside of AEM dialogs, is this AEM Gem of Customizing Dialogs:
https://docs.adobe.com/ddc/en/gems/customizing-dialog-fields-in-touch-ui.html

Good Luck

Avatar

Level 2

Thank you! That was very helpful and I have a more thorough understanding of how client libraries are built.