Hi @SudarshanV1,
1. Use a Sling Model Validator or Custom JS Validation in the Author UI
You can write a custom JavaScript validator that checks the child components under your container component when authors try to add a new one.
If the same component (by resourceType) already exists, show a Coral UI alert and prevent the add.
Example (clientlib JS in your container component):
(function(document, $) {
"use strict";
$(document).on("foundation-contentloaded", function() {
$(".your-container-selector").each(function() {
const container = $(this);
const existing = container.find("[data-resource-type='project/components/content/banner']");
// disable adding Banner again
if (existing.length > 0) {
container.find("[data-type='project/components/content/banner']")
.attr("disabled", true)
.addClass("cq-Editable-dom--disabled");
}
});
});
})(document, Granite.$);
2. Backend Validation — Using Sling Model or Workflow Step
You can implement a custom Sling Model validation that runs on page activation or save event, to ensure only one instance of that component exists.
Example check (in Sling Model or Servlet):
Resource container = resourceResolver.getResource("/content/.../yourcontainer"); Iterator<Resource> children = container.listChildren(); int bannerCount = 0; while (children.hasNext()) { Resource child = children.next(); if ("project/components/content/banner".equals(child.getResourceType())) { bannerCount++; } } if (bannerCount > 1) { throw new ValidationException("Only one Banner component is allowed in this container!"); }
🧠 This approach ensures repository-level validation—useful for publishing workflows or page save hooks.
3. Use an AEM Content Policy Property
You can store a custom policy property (like maxCount.banner=1) and enforce it either:
This makes it configurable per template — best for scalable projects.