Why we need multiple clientlib categories and multiple servlet paths | Community
Skip to main content
sathishreddy
sathishreddy
Level 2
July 25, 2020
Solved

Why we need multiple clientlib categories and multiple servlet paths

  • July 25, 2020
  • 4 replies
  • 6532 views

Hi,

 

could anyone please explain the use cases for below things.

 

We can mention multiple categories for client libraries, so what is the use case to define multiple categories? I  can use single category in JSP/HTML, defining as embeded and defining as dependency.

 

And same for servlets also we can define multiple paths, in which scenario we use multiple paths?

 

Thanks,

Satish

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Nirmal_Jose

 

1.Best use case for a multiple clientlibs can be for optimised pages.You have 20 custom components out of which 4 of them can be used in homepage and all 20 in category pages. In this case, I will choose to create two clientlibs - clientlibs_homepage and clientlibs_all and will load clientlibs_homepage in the homepage. This ensures the page performance is at its best. There could many other use cases like this.

2. For servlets, take a use case of a CRUD operations where only read should be exposed to internet and all functions exposed to author instance. I will create two paths and I will whitelist the only one in the dispatcher filter.

 

Hope this helps,

Nirmal Jose

4 replies

vanegi
Adobe Employee
vanegiAdobe Employee
Adobe Employee
July 25, 2020

Hi @sathishreddy.,

This “categories” property of the String[] type identifies the categories into which the set of JS and/or CSS files within this cq:ClientLibraryFolder fall. The categories property, being multi-valued, allows a library folder to be part of more than one category (see below [0] for how this may be useful).

 

This value will be referenced when including the clientlib in the JSP of a component, as well as defining embedded clientlib inheritance at the template-level.
This categories property is also beneficial because it allows you to group several clientlibs into the same category, so one include can pull as many clientlibs that belong to that category with one CQ include.
For instance, if you place the following CQ includes into the <head>:

<cq:includeClientLib css="project.components" />
<cq:includeClientLib js="project.components" />

It might result in this HTML-output:

<link href="/apps/components/component1/clientlib.css?x32508" rel="stylesheet" type="text/css" />
<link href="/apps/components/component2/clientlib.css?x32508" rel="stylesheet" type="text/css" />
<link href="/apps/components/component3/clientlib.css?x32508" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="/apps/components/component1/clientlib.js?x32508"></script>
<script type="text/javascript" src="/apps/components/component2/clientlib.js?x32508"></script>
<script type="text/javascript" src="/apps/components/component3/clientlib.js?x32508"></script 

 

[0]: https://docs.adobe.com/content/help/en/experience-manager-65/developing/introduction/clientlibs.html

 

 

Thanks!!

    Shashi_Mulugu
    Community Advisor
    Shashi_MuluguCommunity Advisor
    Community Advisor
    July 25, 2020

    In general we use one category for one clientlib and we either invoke in either component/template we maintain or add as embed/dependency to other clientlibs we maintain using that category. General usecase for adding more than one category is to invoke the our own clientlib on the page/context which either shouldn't be modified to add this clientlib or don't have permissions.

     

    Ex: For a custom clientlib used for dialog validation , can have a Category ID X and used as extraclientlibs on to the dialog but if the same validation is generic we can also mention one more page authoring category named cq.authoring.editor.sites.page or cq.authoring.dialog for all touch ui elements.

     

    Similarly for servlets, we can have one servlet with multiple paths for example I have a user managment servlet to create/update/delete/get users I can define either one path with all HTTP methods or define different paths such as /bin/adduser, /bin/removeuser,/bin/updateuser, /bin/user/ and call services respectively

      Prince_Shivhare
      Community Advisor
      Prince_ShivhareCommunity Advisor
      Community Advisor
      July 25, 2020

      Every resource is having its one identity.

      Like clientlib we have Categories, and for the servlet, we have path or resourceType.

       

      what is your use case? I only know embed property where you can include multiple clientLib categories into one.

       

      To recognize a resource, you need some identity and that is one, if you will have multiple, then how you will define it.

        Nirmal_Jose
        Adobe Employee
        Nirmal_JoseAdobe EmployeeAccepted solution
        Adobe Employee
        July 25, 2020

         

        1.Best use case for a multiple clientlibs can be for optimised pages.You have 20 custom components out of which 4 of them can be used in homepage and all 20 in category pages. In this case, I will choose to create two clientlibs - clientlibs_homepage and clientlibs_all and will load clientlibs_homepage in the homepage. This ensures the page performance is at its best. There could many other use cases like this.

        2. For servlets, take a use case of a CRUD operations where only read should be exposed to internet and all functions exposed to author instance. I will create two paths and I will whitelist the only one in the dispatcher filter.

         

        Hope this helps,

        Nirmal Jose

          sathishreddy
          sathishreddyAuthor
          Level 2
          July 25, 2020

          Hi Nirmal,

           

          Thank you for your reply. 

           

          Yes client libraries fine but I am asking multiple categories to single  client library. What is the real time scenario.

           

          Thanks,

          Satish

           

          Terms & ConditionsAccessibility statement

          Loading footer...