Custom Tag Libraries : architecture and reasons to use | Community
Skip to main content
dnelson42
dnelson42
New Participant
October 16, 2015
Solved

Custom Tag Libraries : architecture and reasons to use

  • October 16, 2015
  • 2 replies
  • 1108 views

I am a fairly green Java developer. I have 18 years of overall development experience but only about 1.5 years of Java, and only about that in CQ5. I have taken both the developer and advanced developer courses from Adobe.

I like the idea of a using custom tag library in my CQ projects because I can see how they would improve testability, and code re-use, among other things. However, being fairly new to both Java and CQ5 I don't have a good grasp on exactly what types components would be ideal candidates for a custom tag library, and what an "ideal" overall architecture would be.

So in my cq workspace I have 4 projects:

  • "commons" bundle - shared utility classes, mostly static ones. No business logic.
  • "core" bundle - contains services, servlets, models, listeners, and whatever business logic the write in Java classes.
  • taglib bundle - just what it sounds like
  • "UI" or "content" package for the component jsp files, /etc/designs, etc.

So here are my questions:

  1. How specific or generic do I make the output of custom tags?
  2. Does everything go into the tag, i.e. html, javascript and all?
  3. What is the best way to write Unit tests for a custom tag?
  4. What is the best programming pattern to use for the relationship between the tags and the business logic code?
  5. How does the use of services and servlets fit with custom tag development?

Thanks in advance,

David T Nelson

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 kamran-khan

Hi David,

It's encouraging that unlike a lot of developers you're thinking about taglibs.  I'll try to summarise the way I have used taglibs myself on previous projects.

But firstly, with regards to your Maven project or OSGi bundle structure, there's no set rule... the way I tend to structure things is as follows:

MY_PROJECT
  |- CORE
      |- FILTERS
      |- MODELS
      |- SERVICES
      |- SERVLETS
      |- TAGLIBS
  |- UI

Where MY_PROJECT and CORE are multi-module Maven projects.  FILTERS, MODELS, SERVICES, SERVLETS and TAGLIBS in this case will build into individual OSGi bundles.  Note that on some projects this can be overkill as not many take advantage of OSGi's bundle flexibility whereby it's possible to deploy/release individual project bundles and then to release the entire project anyway... therefore it's acceptable to have FILTERS, MODELS, SERVICES, SERVLETS and TAGLIBS as Java packages rather than bundles.

Coming back to your taglibs questions now:
1. Try to keep them as generic as possible so you get more re-use out of them.
2. No - this is considered an anti-pattern therefore bad-practice.  Depending on the use case, you can write out the value, or create a model against which you can set values via its setters, then add the model to the pageContext so it can be used in the JSP to get to its values.
3. Use frameworks such as Mockito and/or PowerMock.
4. Create Sling Services that contain your business logic and call the methods from your taglibs.
5. Again, this is very use case specific, but note that Sling Servlets tend to handle your doGet or doPost and are primarily bound via ResourceType or ResourcePath.

Depending on which version of CQ/AEM you're working with, you could look at the new framework within Sling --> Sling Models http://sling.apache.org/documentation/bundles/models.html

Hope this gives you something to go by for now.

Regards,
Kamran

2 replies

V
vishalsaini
New Participant
August 28, 2017

Hi kamrankhan84,

This was a very helpful answer. Can you please also elaborate what is the basis to decide which one of servlet and taglib to use in any given scenario?

smacdonald2008​ , bsloki probably you can help us with this question too.

Regards,

Vishal

K
kamran-khanAccepted solution
New Participant
October 16, 2015

Hi David,

It's encouraging that unlike a lot of developers you're thinking about taglibs.  I'll try to summarise the way I have used taglibs myself on previous projects.

But firstly, with regards to your Maven project or OSGi bundle structure, there's no set rule... the way I tend to structure things is as follows:

MY_PROJECT
  |- CORE
      |- FILTERS
      |- MODELS
      |- SERVICES
      |- SERVLETS
      |- TAGLIBS
  |- UI

Where MY_PROJECT and CORE are multi-module Maven projects.  FILTERS, MODELS, SERVICES, SERVLETS and TAGLIBS in this case will build into individual OSGi bundles.  Note that on some projects this can be overkill as not many take advantage of OSGi's bundle flexibility whereby it's possible to deploy/release individual project bundles and then to release the entire project anyway... therefore it's acceptable to have FILTERS, MODELS, SERVICES, SERVLETS and TAGLIBS as Java packages rather than bundles.

Coming back to your taglibs questions now:
1. Try to keep them as generic as possible so you get more re-use out of them.
2. No - this is considered an anti-pattern therefore bad-practice.  Depending on the use case, you can write out the value, or create a model against which you can set values via its setters, then add the model to the pageContext so it can be used in the JSP to get to its values.
3. Use frameworks such as Mockito and/or PowerMock.
4. Create Sling Services that contain your business logic and call the methods from your taglibs.
5. Again, this is very use case specific, but note that Sling Servlets tend to handle your doGet or doPost and are primarily bound via ResourceType or ResourcePath.

Depending on which version of CQ/AEM you're working with, you could look at the new framework within Sling --> Sling Models http://sling.apache.org/documentation/bundles/models.html

Hope this gives you something to go by for now.

Regards,
Kamran

Terms & ConditionsAccessibility statement

Loading footer...