# Nhan AEM Notes

> A personal collection of notes, code snippets, and guides for Adobe Experience Manager (AEM), Java, and web development.

## AEM

- [AEM (Adobe Experience Manager)](https://nhanbe.id.vn/aem/index.md): AEM (Adobe Experience Manager) Index - Architecture - Foundation - Backend - Content & Data - UI - Infrastructure - AEM Articles
- [AEM Core Architecture](https://nhanbe.id.vn/aem/architecture.md): The core philosophy is everything is content. Pages, components, templates, configurations, code-resolved scripts - they all live as nodes in the JCR.
- [Building Homepage & Article Page](https://nhanbe.id.vn/aem/foundation/building-pages.md): Practice: Building component for home page.
- [Client Libraries](https://nhanbe.id.vn/aem/foundation/client-libraries.md): Client libraries AEM basic
- [Component Dialogs](https://nhanbe.id.vn/aem/foundation/component-dialogs.md): Basic Dialog Structure On Touch UI, all dialogs follow a strict nested XML structure built using Granite UI libraries.
- [Content Fragments & GraphQL](https://nhanbe.id.vn/aem/foundation/content-fragments-and-graphql.md): Content Fragments are **structured, channel-neutral content*— text, images, data — stored independently of any page layout. Combined with GraphQL,
- [HTL Templates](https://nhanbe.id.vn/aem/foundation/htl-templates.md): HTL (formerly Sightly) is AEM's server-side template language. It completely replaces JSP and serves as the standard for rendering components. HTL'
- [Introduction to AEM](https://nhanbe.id.vn/aem/foundation/introduction-to-aem.md): Adobe Experience Manager (AEM) is a content management system (CMS) built on Java. It manages websites, digital assets, and content across channel
- [JCR & Sling](https://nhanbe.id.vn/aem/foundation/jcr-and-sling.md): JCR is a hierarchy, tree-structured content repository. JCR has nodes and properties. Nodes are like folders. They have a name, type, and contain
- [JCR Page Properties & jcr:content Node](https://nhanbe.id.vn/aem/foundation/jcr-page-properties.md): All properties on the jcr:content node of an AEM page
- [OSGi Fundamentals](https://nhanbe.id.vn/aem/foundation/osgi-fundamentals.md): OSGi is the module system managing all Java code in AEM. Every Java piece — your code, AEM's code, third-party libraries — runs inside an **OSGi
- [Publishing And Replication](https://nhanbe.id.vn/aem/foundation/Publishing-and-Replication.md): Build pages and assets on the **author*instance. Visitors never see author tier they see publisher, fronted by the Dispatcher and a CDN. Replication
- [Sling Model](https://nhanbe.id.vn/aem/foundation/sling-model.md): --**Flow Summary (HTL):*1. `data-sly-use` points to a class annotated with `@Model`. 2. Sling creates an instance and injects fields. 3. HTL use
- [Templates & Policies](https://nhanbe.id.vn/aem/foundation/templates-and-policies.md): **Template**: determines **page structure*and **authoring regions**. **Policy**: determines **allowed components*+ **default/design options*+
- [Testing and Debugging](https://nhanbe.id.vn/aem/foundation/testing-and-debugging.md): What it cover: Sling Models, services, utility logic in isolation Tooling: JUnit 5, Mockito, wcm.io AEM Mocks (`AEMContext`) `AEMContext` from
- [Your First Component](https://nhanbe.id.vn/aem/foundation/your-first-component.md): Components are the primary building blocks of AEM pages. A button, a text block, a carousel, or a hero banner — each of these elements is a
- [Context-Aware Configuration](https://nhanbe.id.vn/aem/backend/context-aware-configuration.md): Sling Context-Aware Configuration (CA Config) lets you store configuration values
- [Event Listeners and Handlers](https://nhanbe.id.vn/aem/backend/event-listener-and-handler.md): AEM provides two event systems for reacting to changes in the repository and the platform. Understanding
- [AEM Filters](https://nhanbe.id.vn/aem/backend/filters.md): Sling servlet filters sit between the Sling engine and the servlet (or script) that ultimately handles a request. They intercept every request tha
- [Java Best Practices in AEM](https://nhanbe.id.vn/aem/backend/java-best-practice-aem.md): This page collects practical Java guidelines for AEM projects. The goal is consistent, safe code that is easy to test and maintain.
- [OSGi Configuration](https://nhanbe.id.vn/aem/backend/osgi-configuration.md): OSGi configuration must be deployed via code (content package), not manually edited in Felix Console. Easy PR review Git history tracking
- [AEM Servlets](https://nhanbe.id.vn/aem/backend/servlets.md): Sling Servlets are Java classes that handle HTTP requests in AEM. They are the standard way to build
- [Sling Jobs and Scheduler](https://nhanbe.id.vn/aem/backend/sling-jobs-and-scheduler.md): AEM's background processing is built on two complementary mechanisms:
- [Sling Models and Services](https://nhanbe.id.vn/aem/backend/sling-model-and-services.md): Sling Models are annotation-driven Java classes that automatically map AEM content (JCR properties,
- [AEM Workflows](https://nhanbe.id.vn/aem/backend/workflows.md): AEM Workflows are automated, multi-step processes that model real-world business operations inside Adobe
- [Content Fragments](https://nhanbe.id.vn/aem/content-and-data/content-fragment.md): Guide to authoring and managing structured Content Fragments in AEM.
- [Content Fragments & GraphQL](https://nhanbe.id.vn/aem/content-and-data/content-fragments-and-graphql.md): Delivering structured Content Fragments via AEM GraphQL APIs for headless applications.
- [Experience Fragment - XF](https://nhanbe.id.vn/aem/content-and-data/experience-fragment.md): Authoring, managing, and reusing Experience Fragments across channels in AEM.
- [Headless GraphQL](https://nhanbe.id.vn/aem/content-and-data/graphql.md): Setting up and executing GraphQL queries for headless content delivery in AEM 6.5.
- [i18n và Translation](https://nhanbe.id.vn/aem/content-and-data/i18n-translation.md): Managing UI string translations dictionary and multi-language content in AEM.
- [Hướng dẫn Truy vấn & Sửa đổi JCR](https://nhanbe.id.vn/aem/content-and-data/modify-and-query-the-jcr.md): Comprehensive guide for querying and modifying JCR repository nodes and properties.
- [Multi-Site Manager (MSM)](https://nhanbe.id.vn/aem/content-and-data/multi-site-manager-msm.md): Managing multi-site blueprints, live copies, and rollout configurations with AEM MSM.
- [JCR Node Operations](https://nhanbe.id.vn/aem/content-and-data/node-operation.md): Comparing Sling Resource API and JCR Node API for repository CRUD operations.
- [Query Builder](https://nhanbe.id.vn/aem/content-and-data/query-builder.md): In-depth guide to AEM QueryBuilder predicates, pagination, indexing, and optimization.
- [Replication và Activation](https://nhanbe.id.vn/aem/content-and-data/replication-activation.md): Understanding AEM replication agents, content activation workflow, and Dispatcher flush mechanism.
- [Tags và Taxonomies](https://nhanbe.id.vn/aem/content-and-data/tags-taxonomies.md): Managing JCR tags, taxonomies, and tagging APIs in Adobe Experience Manager.
- [Coral Ui](https://nhanbe.id.vn/aem/ui/coral-ui.md): Coral Ui - developer documentation and reference notes for Coral Ui.
- [Custom Dialog Widgets](https://nhanbe.id.vn/aem/ui/custom-dialog-widgets.md): Custom Dialog Widgets - developer documentation and reference notes for Custom Dialog Widgets.
- [Extending Responsive Grid](https://nhanbe.id.vn/aem/ui/extending-responsive-grid.md): Extending Responsive Grid - developer documentation and reference notes for Extending Responsive Grid.
- [Webpack](https://nhanbe.id.vn/aem/ui/multi-tenancy-ui-frontend.md): Webpack - developer documentation and reference notes for Webpack.
- [Overlays trong AEM 6.5](https://nhanbe.id.vn/aem/ui/overlays.md): Overlays trong AEM 6.5 - developer documentation and reference notes for Overlays trong AEM 6.5.
- [Render Conditions](https://nhanbe.id.vn/aem/ui/render-conditions.md): Render Conditions - developer documentation and reference notes for Render Conditions.
- [AEM SPA Editor](https://nhanbe.id.vn/aem/ui/spa-editor.md): AEM SPA Editor - developer documentation and reference notes for AEM SPA Editor.
- [Touch UI / Author UI](https://nhanbe.id.vn/aem/ui/touch-ui-2.md): Touch UI / Author UI - developer documentation and reference notes for Touch UI / Author UI.
- [Touch Ui](https://nhanbe.id.vn/aem/ui/touch-ui.md): Touch Ui - developer documentation and reference notes for Touch Ui.
- [ACL & Permissions](https://nhanbe.id.vn/aem/infrastructure/acl-permissions.md): ACL & Permissions - developer documentation and reference notes for ACL & Permissions.
- [AEM Dispatcher, Cache và Flush Cache trong AEM 6.5 On-Premise](https://nhanbe.id.vn/aem/infrastructure/dispatcher-cache-flush.md): Understanding AEM Dispatcher caching mechanics, stat files, and cache invalidation flush agents in AEM 6.5.
- [Dispatcher: Cấu hình Cache và Rủi ro](https://nhanbe.id.vn/aem/infrastructure/dispatcher-config-risks.md): Analyzing AEM Dispatcher caching configurations, security rules, and common deployment risks.
- [MSM (Multi Site Manager) trong AEM 6.5](https://nhanbe.id.vn/aem/articles/msm/basic-msm-in-aem.md): MSM cho phép nội dung nguồn được tái sử dụng ở nhiều site đích với cơ chế COPY-based. Hướng dẫn chi tiết về Blueprint, Live Copy, Rollout Config, Live Action và API.
- [Sling Framework - Basic](https://nhanbe.id.vn/aem/articles/sling/sling-framework.md): Introduction to Apache Sling RESTful framework, resource mapping, and JCR content architecture.
- [Sling Model Annotations](https://nhanbe.id.vn/aem/articles/sling/sling-model-annotations.md): Complete reference for Apache Sling Model annotations and field injectors.
- [AEM - Code Execute flow](https://nhanbe.id.vn/aem/articles/10-authoring-publishing-dispatcher-code-env.md): Understand the boundaries and execution flow differences between AEM Author, Publish, Dispatcher, and CDN.
- [AEM Externalizer — Hướng dẫn sử dụng trong dự án mysite](https://nhanbe.id.vn/aem/articles/aem-externalizer-guide.md): Guide to configuring and using AEM Externalizer service to build absolute URLs across environments.
- [Khai thác Classic UI để debug trên AEM hiện đại](https://nhanbe.id.vn/aem/articles/classic-ui-debugging.md): Debugging guide utilizing Classic UI consoles and tools in modern AEM 6.5.
- [Cloudflare](https://nhanbe.id.vn/aem/articles/cloudflare-api-cache.md): Best practices for setting up Cloudflare CDN caching in front of AEM API endpoints.
- [Touch UI Principal-Based Permission Management](https://nhanbe.id.vn/aem/articles/experience-manager-65-touch-ui-principal-view.md): AEM 6.5 introduces Permissions Management for Users and Groups. The main functionality remains the same as the classic UI, but is more user-friendly
- [Hướng dẫn tạo Custom Page Template trong AEM 6.5](https://nhanbe.id.vn/aem/articles/impl_custom_page_template_guide.md): Guide to creating and configuring custom page templates in AEM 6.5.
- [Implement SEO JSON-LD Schema cho Page Component](https://nhanbe.id.vn/aem/articles/impl-seo-schema.md): Implementation guide for structured data JSON-LD generation in AEM using Sling Models and HTL.
- [User Administration and Security](https://nhanbe.id.vn/aem/articles/security-aem65.md): Overview of user administration, groups, privileges, and security configurations in AEM 6.5.
- [SEO LD+JSON: xây dựng object lồng nhau cho AEM Page](https://nhanbe.id.vn/aem/articles/seo-ld-json-nested.md): Advanced guide for building nested JSON-LD structured data objects in AEM.
- [Seo Ld Json](https://nhanbe.id.vn/aem/articles/seo-ld-json.md): Fundamental approach for implementing JSON-LD structured data pipeline in AEM.
- [Child Resource](https://nhanbe.id.vn/aem/annotations/child-resource.md): The @ChildResource annotation is a Sling Models injector that maps child JCR nodes to Java objects. It is the
- [Externalized ValueMap](https://nhanbe.id.vn/aem/annotations/externalized-value-map-value.md): @ExternalizedValueMapValue is a custom Sling Models injector annotation that reads a JCR property (like
- [Sling Model Annotations](https://nhanbe.id.vn/aem/annotations/sling-model-annotations-reference.md): This page is a comprehensive reference for all commonly used Sling Model annotations. Each annotation is explained
- [Client Libraries](https://nhanbe.id.vn/aem/client-libraries.md): Client libraries (clientlibs) are AEM's mechanism for managing CSS and JavaScript delivery. They provide dependency management, aggregation,
- [AEM Components Overview](https://nhanbe.id.vn/aem/component/component-overview.md): An AEM component is a self-contained building block that authors drag onto a page, configure via a dialog,
- [AEM Core Components](https://nhanbe.id.vn/aem/component/core-component.md): This post explains, how you can extend the functionality of AEM Core Components. Part 1 focuses on the extension and reusability of the core
- [Decoration Tag (cq:htmlTag)](https://nhanbe.id.vn/aem/component/decoration-tag.md): How AEM wraps components in a decoration element, and how to control its tag name and CSS classes with cq:htmlTag.
- [Dialog Validation](https://nhanbe.id.vn/aem/component/dialog-validation.md): AEM's Touch UI dialog framework includes a client-side validation system that lets you enforce business
- [Templates and Policies](https://nhanbe.id.vn/aem/component/template-and-policies.md): Editable Templates are AEM's modern template system. They let template authors define
- [Touch UI Component Dialogs](https://nhanbe.id.vn/aem/component-dialogs.md): The following chapters each present a Coral XML snippet which can be copied into any /components/mycomponent/cqdialog/.content.xml file.
- [Custom AEM Components](https://nhanbe.id.vn/aem/custom-component.md): This guide walks through creating a custom AEM component from start to finish. Every artifact is covered:
- [HTL Templates (Sightly)](https://nhanbe.id.vn/aem/htl-templates.md): HTL (HTML Template Language), formerly known as Sightly, is AEM's server-side template language. It is the
- [Standalone ACS Common Overview](https://nhanbe.id.vn/aem/standanlone-acs-common/acs-common-overview.md): [GitHub Repository](https://github.com/LucaNerlich/standalone-acs-commons) [ACS AEM Commons](https://adobe-consulting-services.github.io/acs-aem-comm
- [AEM Advance topic](https://nhanbe.id.vn/aem/advanced/index.md)
- [AEM as a Cloud Service](https://nhanbe.id.vn/aem/advanced/aem-as-a-cloud-service.md)
- [AEM Client Libraries (Clientlibs)](https://nhanbe.id.vn/aem/advanced/client-libraries.md): #base=css variables.less mixins.less base/typography.less base/layout.less components/product-hero.less components/spec-table.less components/downloads.lessCopy Copy clientlib-product/js.txt #base=js utils/dom.js utils/analytics.js components/spec-table.js components/downloads.js main.jsCopy Copy What to point at in an interview: The #base= line sets the folder, so variables.less means css/variables.less. The ordering is deliberate and load-bearing: variables, then base, then components. Alphabetical order would put base before variables and break every variable reference. main.js is last, because it initialises things the other modules define. 8.3 A component-level clientlib ui.apps/.../apps/energy/components/accordion/clientlibs/.content.xml <jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" jcr:primaryType="cq:ClientLibraryFolder" categories="[energy.component.accordion]"/>Copy Copy Note what is absent: allowProxy. That is deliberate, and it is the answer to a good follow-up question. This clientlib is embedded into energy.product and energy.editorial, so the browser never requests it directly. Adding allowProxy here would expose it unnecessarily for no benefit. 8.4 The page component — calling clientlibs correctly ui.apps/.../apps/energy/components/page/page.html CSS in the head, JS at the end of the body. CSS in the head means the browser has styles before it paints, so there is no unstyled flash. A blocking script in the head halts HTML parsing until it downloads and runs. Categories from the page policy, not hardcoded. This is the direct link to file 03. One page component, different bundles per template. async on analytics. Nothing on the page depends on it, so it should never delay anything. 8.5 Reading the page policy's clientlib categories package com.energy.core.models; import com.day.cq.wcm.api.designer.Style; import org.apache.sling.api.SlingHttpServletRequest; import org.apache.sling.models.annotations.DefaultInjectionStrategy; import org.apache.sling.models.annotations.Model; import org.apache.sling.models.annotations.injectorspecific.ScriptVariable; import javax.annotation.PostConstruct; import java.util.Arrays; import java.util.List; @Model( adaptables = SlingHttpServletRequest.class, defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL ) public class PageModel { }Copy Copy The key line is currentStyle.get("clientlibs", ...). currentStyle is the resolved policy for this component on this template — that is the bridge between file 03's page policy and this file's clientlib categories. Note also the model adapts from SlingHttpServletRequest rather than Resource, because @ScriptVariable for currentStyle needs request context. That is a real distinction covered properly in file 05. 8.6 The dispatcher rule that must exist dispatcher/src/conf.dispatcher.d/filters/filters.any (extract) /0001 { /type "deny" /glob "*" } /0100 { /type "allow" /path "/etc.clientlibs/*" /extension '(css|js|jpg|jpeg|png|gif|svg|woff|woff2|ttf|eot)' }Copy Copy Say this in an interview: allowProxy and the dispatcher filter are two independent gates, and both must pass. They produce an identical symptom — a 404 on the CSS — but you tell them apart by whether the request reached AEM at all. Check the dispatcher log; if it never got through, it is the filter. Common Mistakes The mistake	What actually happens	The fix allowProxy missing on a served clientlib	404 on publish, works on author	allowProxy="{Boolean}true" allowProxy="true" without {Boolean}	Stored as a string; the proxy ignores it. Looks correct in the XML.	Add the type hint Dispatcher not allowing /etc.clientlibs	Identical 404, one layer earlier	Add the filter rule Missing or empty js.txt	No JavaScript at all, silently — no error	Create it, list files in order Wrong order in css.txt	Variables load after the styles using them; everything breaks subtly	Variables → base → components Listing a folder instead of files	Alphabetical order, almost always wrong	List files explicitly Editing generated css.txt / js.txt	Overwritten on the next ui.frontend build	Change the webpack config instead Two bundles embedding the same clientlib	Code shipped and executed twice; JS handlers bind twice	One embedder per component clientlib One giant site-wide bundle	Every page downloads everything	Split by page type via page policies Hardcoding categories in the page component	Every page type gets the same bundle	Read them from the page policy allowProxy on component clientlibs that are embedded	Unnecessary exposure, more places to get wrong	Only page-level bundles need it Assets outside resources/	Relative url() in CSS 404s	Put fonts and images in resources/ No versioning on 6.5	Users see stale CSS for days after a deploy	ACS Commons Versioned ClientLibs JS in the <head> without defer	Blocks HTML parsing, delays first paint	End of body, or defer Component JS using IDs / global selectors	Two instances on one page conflict	Scope to the component's own element Author-only styling in the site bundle	Shipped to every visitor for no reason	Separate category, included conditionallyBest Practices On structure. Layer it: a base clientlib every page loads, page-type bundles selected by page policy, and component clientlibs embedded into those bundles. Resist the single site-wide bundle — it is the default drift and it is what makes pages slow. On categories. Namespace them — energy.base, energy.product, energy.component.accordion. Be deliberate about sharing a category across folders, because it means requesting that category pulls in all of them. On allowProxy. Set it only on clientlibs the browser actually requests. Embedded ones do not need it. Always use the {Boolean} type hint. On css.txt and js.txt. Order deliberately — variables, then base, then components. List files explicitly rather than folders. If they are generated by ui.frontend, do not hand-edit them. On embed versus dependencies. Embed component clientlibs into bundles to avoid a request per component. Use dependencies only for a genuine ordering requirement. Keep a rule that each component clientlib is embedded by exactly one bundle. On loading. CSS in the head, JS at the end of the body. async for anything nothing depends on, like analytics. media="print" for print styles so they never block rendering. On caching. Versioned URLs, always. On Cloud Service it is built in; on 6.5 use ACS Commons. Then you can safely set a long TTL, which is the actual win. On the front-end workflow. Use ui.frontend so the front-end team gets modern tooling and does not need an AEM instance to work. Debugging Tips The single most useful trick: add ?debugClientLibs=true to any page URL. Instead of one merged, minified file you get the individual source files listed separately and unminified — so you can see exactly what is being included, in what order, and read the actual CSS. The dumplibs tooling — worth memorising at least the first path: /libs/granite/ui/content/dumplibs.html → every clientlib registered, with its categories, dependencies and embeds /libs/granite/ui/content/dumplibs.test.html?categories=energy.product → exactly what a given category resolves to, in order /libs/granite/ui/content/dumplibs.validate.html → flags duplicate categories and other issues /libs/granite/ui/content/dumplibs.rebuild.html → force a rebuild of the generated outputCopy Copy The diagnostic flow for "my styling isn't there": graph TD A["No styling on the page"] --> B{"Is the <link> tag<br/>in the HTML?"} B -->|No| C["Category wrong, or the<br/>page policy has no clientlibs"] B -->|Yes| D{"Does the URL 404<br/>in the network tab?"} D -->|No| E["File loaded — it's a CSS<br/>problem, not a clientlib one"] D -->|Yes| F{"Did the request reach AEM?<br/>check dispatcher.log"} F -->|No| G["DISPATCHER FILTER<br/>blocking /etc.clientlibs"] F -->|Yes| H["ALLOWPROXY<br/>missing or stored as a string"] ⛶ Fullscreen Splitting the problem the same way as always: is the reference wrong, or is the fetch failing? The <link> tag being present tells you the page and the policy are fine, and the problem is delivery. When a change doesn't appear: Rebuild the clientlibs via the dumplibs rebuild page — the generated output is cached. Hard refresh the browser, or check in a private window. Flush the dispatcher. If it is production, remember the CDN. When you suspect duplication: load with ?debugClientLibs=true and look for the same file listed twice, or search the merged output for a distinctive function name. Tool	What it tells you ?debugClientLibs=true	Individual unminified files, in order dumplibs.html	All clientlibs, categories, embeds, dependencies dumplibs.test.html?categories=X	What one category actually resolves to dumplibs.rebuild.html	Force regeneration Browser network tab	Whether the fetch 404s, and the response headers dispatcher.log	Whether the request even reached AEM DevTools → Coverage	How much of your CSS/JS actually executes 12. Performance Optimization Clientlibs are usually the largest front-end performance lever in an AEM project, so this section matters more than it does in most files. Split by page type. This is almost always the biggest single win. One site-wide bundle means every page downloads the campaign carousel, the interactive map, and the data-table library whether it uses them or not. Page policies make the split free — no code change, just different categories per template. Measure before cutting. Chrome DevTools has a Coverage tab that shows exactly what proportion of each file executes on a given page. Guessing what is unused is how you break things. Load CSS in the head, JS at the end of the body. CSS is render-blocking by design, which is what you want — the page should not paint unstyled. JavaScript blocking the parser is not what you want. Use async and defer appropriately. async for anything nothing depends on and whose order does not matter, like analytics. defer for scripts that need the DOM parsed but should not block it. Non-blocking print styles. media="print" means the browser downloads it at low priority and it never blocks rendering. Versioned URLs plus a long TTL. This is the caching win. Without versioning you cannot safely set a long TTL, because you have no way to force a refresh. With it, you can cache for a year. Watch for embed duplication. Two bundles embedding the same library means shipping it twice. Consider critical CSS for the highest-traffic templates — inline the above-the-fold styles and load the rest asynchronously. Real gain, real maintenance cost; worth it on a landing page, usually not everywhere. Load genuinely heavy, rare things on demand. A map library or video player used on a handful of pages should not be in the main bundle. Numbers worth quoting: aim for well under 200KB of JavaScript on a typical content page, and check Largest Contentful Paint under 2.5 seconds. Real Production ScenariosCSS works on author, missing on publish. allowProxy not set, or set as a string without {Boolean}. The single most common clientlib incident.Same symptom, but allowProxy is correct. The dispatcher is not allowing /etc.clientlibs. Distinguish by whether the request reached AEM.No JavaScript at all, no error. js.txt missing or empty.Styles apply in the wrong order. Wrong order in css.txt, or a folder listed instead of files so it went alphabetical.Users still see old CSS days after a deploy. No versioned URLs. The URL never changed, so nothing refetched.A source change doesn't appear even after a hard refresh. The generated output is cached — rebuild via dumplibs. Then check dispatcher and CDN.A JavaScript event fires twice. The clientlib is duplicated — two bundles embedding the same one, so the handler binds twice.Fonts or background images 404. They are not in the resources/ folder, so the relative path does not resolve through the proxy.Unexpected CSS appearing on a page. Another clientlib declares the same category, so it is included too.Page is slow, huge JavaScript payload. One site-wide bundle. Split by page type using page policies.Component works in isolation, breaks with two on a page. Component JS using IDs or document-wide selectors rather than scoping to its own element.Author-only styling visible to visitors. Authoring clientlib included in the site bundle instead of conditionally.Front-end changes keep getting reverted. Someone is editing the generated css.txt or js.txt by hand instead of the ui.frontend source.Clientlib works locally, missing on the server. Not included in the package filter, so it never deployed.Print stylesheet blocking page render. Loaded without media="print".LESS compilation errors after a merge. A file listed in css.txt no longer exists, or a variable moved after the file that uses it.Category renamed and half the site lost styling. Categories are referenced from page policies too, not just HTL — those need updating as well.Two page types accidentally sharing a bundle. Both templates' page policies point at the same categories.Analytics script delaying first paint. Loaded synchronously instead of async./etc.clientlibs returns 403 rather than 404. Usually an ACL or a dispatcher rule that matches but denies, rather than the path being absent.Follow-up Questions How many clientlibs does your project have? How is your front-end code built — in AEM, or in ui.frontend? Do you write LESS or SASS? How big is the JavaScript payload on a typical page? How do different page types get different bundles? How do you handle cache busting? Have you had the publish 404 problem? Do component clientlibs get embedded or served individually? Who owns the front-end build on your team? What would you change about how your project handles clientlibs? For the last one: "Our base bundle has grown over time — things get added to it because it's the easy place, and nobody removes anything. I'd want a size budget enforced in the build so it fails when the base bundle grows past a threshold."Comparison Tables categories vs embed vs dependencies — the syllabus comparison categories	dependencies	embed What it is	The name this library answers to	Load another category first	Pull another category inside Direction	Names this library	Points at others	Points at others Result	—	Separate files	One merged file HTTP requests	—	More	Fewer Order guaranteed	—	Yes	Yes (it's one file) Target needs allowProxy	—	Yes	No Use for	Naming and grouping	jQuery before a plugin	Component clientlibs into a bundle Risk	Accidental sharing	Extra requests	Duplication Clientlib locations Pre-6.4	Current Path	/etc/clientlibs/<project>	/apps/<project>/clientlibs Publicly readable	Yes	No Served via	Directly	/etc.clientlibs proxy Needs allowProxy	No	Yes, if served directly clientlib.all vs .css vs .js Outputs	Where to put it clientlib.all	Both <link> and <script>	Rarely ideal clientlib.css	Just the <link>	In <head> clientlib.js	Just the <script>	End of <body> Component clientlib vs site clientlib Component clientlib	Site / page-type bundle Lives in	The component folder	/apps/<project>/clientlibs Category	Narrow, e.g. energy.component.cta	Broad, e.g. energy.product allowProxy	Not needed if embedded	Required Served directly	No	Yes Good for	Components used on some pages	Everything a page type needs Where allowProxy is needed Clientlib	Requested by browser?	allowProxy? Page-level bundle	Yes	Yes Component clientlib, embedded	No	No Author-only clientlib on publish	No	No Anything referenced directly in HTL	Yes	Yes 16. Memory Tricks Why allowProxy exists: "Apps is private, etc.clientlibs is the doorway." Code lives somewhere the public cannot read, so there is a controlled opening. The author/publish trap: "Authors are logged in; visitors are not." That one sentence explains why it works on author and fails on publish. embed vs dependencies: "Dependencies are neighbours, embeds are ingredients." A neighbour has their own house and arrives first; an ingredient goes inside the dish. Which needs allowProxy: "Only what the browser asks for." Embedded libraries are never asked for directly. css.txt order: "Variables, base, components." Never alphabetical. Where to put them: "CSS up top, JS at the bottom." The two gates: "Dispatcher first, allowProxy second." Same 404, two causes, and the dispatcher log tells you which. Categories: "Ask by name, not by address." Same principle as sling:resourceType. Revision Notes A clientlib is a cq:ClientLibraryFolder holding CSS, JS and resources. AEM merges, minifies, orders and serves it. Why: fewer requests, minification, controlled order, reference by category not path, and versioned URLs for cache busting. Location: /apps/<project>/clientlibs. Was /etc/clientlibs before AEM 6.4. Folder contents: .content.xml, css.txt, js.txt, css/, js/, resources/ (served as-is — fonts and images go here). css.txt / js.txt declare which files and in what order. #base= sets the folder. Missing js.txt = no JS at all, silently. Generated by the build if you use ui.frontend — do not hand-edit. categories = the logical name. One lib can have several; several libs can share one (all included). allowProxy="{Boolean}true" = lets the browser fetch it via /etc.clientlibs, which is the clientlib path with /apps stripped. Needed because anonymous users can't read /apps. Works on author, 404s on publish without it. The {Boolean} hint is mandatory. Two independent gates produce that same 404: the dispatcher filter allowing /etc.clientlibs, and allowProxy. Tell them apart via dispatcher.log. dependencies = load another category first, as a separate file. Transitive. embed = pull another category's content into this file. One request. Embedded libs don't need allowProxy. Risk: duplication if two bundles embed the same one. Include with data-sly-use the clientlib template + data-sly-call — .all, .css, .js. CSS in head, JS at end of body. Core Components template supports async, defer, media. Categories come from the page policy (file 03) — that's how one page component ships different bundles per template. Versioned URLs: built in on AEMaaCS, ACS Commons Versioned ClientLibs on 6.5. Debug: ?debugClientLibs=true, and /libs/granite/ui/content/dumplibs.html.Cheat Sheet Folder structure /apps/<project>/clientlibs/clientlib-site/ .content.xml      cq:ClientLibraryFolder + config css.txt           which CSS files, in order js.txt            which JS files, in order css/              LESS/CSS source js/               JS source resources/        served AS-IS: fonts, imagesCopy Copy .content.xml properties jcr:primaryType="cq:ClientLibraryFolder" categories="[energy.product]"           the logical name(s) allowProxy="{Boolean}true"              servable via /etc.clientlibs dependencies="[energy.base,jquery]"     load first, SEPARATE files embed="[energy.component.cta]"          pull INSIDE, ONE fileCopy Copy css.txt / js.txt #base=css          set the source folder variables.less     one file per line base.less          IN LOAD ORDER components.lessCopy Copy Proxy path translation /apps/energy/clientlibs/clientlib-site ↓  strip /apps /etc.clientlibs/energy/clientlibs/clientlib-site.css /etc.clientlibs/energy/clientlibs/clientlib-site/resources/fonts/x.woff2Copy Copy Including in HTL <sly data-sly-call="${clientlib.css @ categories='energy.site'}"/>       in <head> <sly data-sly-call="${clientlib.js  @ categories='energy.site'}"/>       end of <body> <sly data-sly-call="${clientlib.all @ categories='energy.site'}"/>       both @ async=true       don't block, order not guaranteed @ defer=true       run after parsing @ media='print'    non-blocking print stylesCopy Copy Granite alternative <sly data-sly-use.clientlib="/libs/granite/sightly/templates/clientlib.html"/>Copy Copy Legacy JSP <cq:includeClientLib categories="energy.site"/>Copy Copy Debug URLs ?debugClientLibs=true                                     unminified, individual files /libs/granite/ui/content/dumplibs.html                    all clientlibs /libs/granite/ui/content/dumplibs.test.html?categories=X  what X resolves to /libs/granite/ui/content/dumplibs.validate.html           duplicate categories /libs/granite/ui/content/dumplibs.rebuild.html            force rebuildCopy Copy Dispatcher rule /0100 { /type "allow" /path "/etc.clientlibs/*" /extension '(css|js|png|jpg|svg|woff|woff2)' }Copy Copy OSGi config — HTML Library Manager com.adobe.granite.ui.clientlibs.impl.HtmlLibraryManagerImpl debug     · minify · gzip · timingCopy Copy 19. Frequently Forgotten Things allowProxy needs the {Boolean} type hint. allowProxy="true" is a string and is silently ignored. It works on author and fails on publish — because authors are authenticated and can read /apps. Two independent gates cause the same 404: the dispatcher filter and allowProxy. An embedded clientlib does not need allowProxy. A missing js.txt produces no JavaScript, silently. No error at all. #base= is relative to the clientlib folder, and files listed are relative to that base. Listing a folder gives alphabetical order, which is nearly always wrong. resources/ is served as-is — that's where fonts and CSS-referenced images belong. Several clientlibs can share one category, and all of them get included. Embed duplicates code if two bundles embed the same library. Dependencies are transitive; embeds are a flat copy. Clientlib output is cached — rebuild via dumplibs if a change doesn't appear. css.txt / js.txt are generated when you use ui.frontend. Editing them by hand gets overwritten. Categories are referenced from page policies too, not just HTL — renaming one means updating both. Clientlibs moved from /etc/clientlibs to /apps in AEM 6.4, and the proxy exists because of that move. 20. Final Interview Summary What it is. A cq:ClientLibraryFolder holding CSS, JS and resources, managed by AEM.Why. Fewer requests, minification, controlled order, reference by category not path, versioned URLs for cache busting.Where. /apps/<project>/clientlibs since 6.4. That move is why the proxy exists.css.txt and js.txt. Which files, and in what order. Order is load-bearing. Missing means nothing ships.categories. The logical name. One lib can have several; several libs can share one.allowProxy. Lets the browser fetch via /etc.clientlibs, because anonymous users can't read /apps. Works on author, 404s on publish without it. Needs the {Boolean} hint.dependencies vs embed. Neighbours versus ingredients. Separate files versus one merged file. Embedded libraries don't need allowProxy; embed risks duplication.How to include. The clientlib HTL template, .css in the head and .js at the end of the body, with categories coming from the page policy.Performance. Split by page type via page policies — usually the biggest single win. Measure with the Coverage tab before cutting.The war story. The publish 404, the two possible causes, and how you told them apart. That's the answer that shows you've shipped.Mock Interview How to use this: cover the answers, 25-minute timer, speak every answer out loud. The interviewer asks: What is a clientlib? Why do we use clientlibs instead of just linking CSS files? Where do clientlibs live, and where did they used to live? What are css.txt and js.txt, and why are they needed? What happens if js.txt is missing? What is the resources folder for? How do you include a clientlib in HTML? Why put CSS in the head and JavaScript at the end of the body? What is a category? Can two clientlibs share one? What is allowProxy and why do we set it to true? Why does the styling work on author but not on publish? What is /etc.clientlibs and how is the path derived? What's the difference between embed and dependencies? Does an embedded clientlib need allowProxy? What's the risk of using embed? How do product pages and news pages load different CSS from the same page component? Users see old CSS after a deployment. Why, and how do you fix it? How do you debug a clientlib that isn't loading? What is the ui.frontend module? A page loads 400KB of unused JavaScript. How do you approach it? Model answers A folder in the repository of node type cq:ClientLibraryFolder holding CSS, JavaScript and related assets, which AEM merges, minifies, orders and delivers to the browser. It contains a .content.xml with the configuration, css.txt and js.txt declaring the files and their order, the source folders, and a resources folder for things served as-is.Five reasons. AEM merges many source files into a single request rather than dozens. It minifies automatically. It resolves load order from what we declare, instead of us maintaining it by hand in every template. It lets us reference a library by a logical category name rather than a hardcoded path — same indirection principle as sling:resourceType pointing at a component. And it can put a content hash in the URL so a deployment actually invalidates browser and CDN caches. Without that last one, users see stale CSS for days./apps/<project>/clientlibs. Before AEM 6.4 they lived under /etc/clientlibs, and the repository restructuring moved them into /apps where application code belongs. That move created a problem, though — /apps isn't readable by anonymous users — which is exactly why the /etc.clientlibs proxy exists.They declare which source files belong to the library and, crucially, the order they're concatenated in. Order matters enormously: in CSS the cascade depends on it, so variables and base styles must come before the component styles built on them; in JavaScript a module has to be defined before anything calls it. If AEM just included everything in the folder, you'd get alphabetical order, which would put variables after base and break everything. The syntax is a #base= line setting the source folder, then one file per line in load order.The clientlib produces no JavaScript at all — and silently. No error, no warning, just nothing in the output. It's a confusing failure because everything else looks fine.Files served as-is rather than merged and minified — fonts, images, anything the CSS references by a relative path. It matters because those files are served through the proxy at their relative path, so url('resources/fonts/icons.woff2') in your CSS resolves correctly. Put a font anywhere else in the clientlib and it 404s.data-sly-use the clientlib template — either the Granite one at /libs/granite/sightly/templates/clientlib.html or the Core Components one, which I prefer because it supports async, defer and media. Then data-sly-call with a categories parameter. There are three calls: all, css and js. I almost always use css and js separately rather than all, so I can put them in the right places.CSS in the head means the browser has the styles before it paints, so the page never flashes unstyled. A blocking <script> in the head stops HTML parsing until it downloads and executes, which delays first paint — so JavaScript goes at the end of the body, or uses defer. For anything nothing depends on, like analytics, I use async so it never delays anything.A category is the logical name a clientlib answers to, so code asks for energy.product rather than a repository path — which means the folder can move or be renamed without breaking anything. And yes, several clientlibs can share one category, in which case requesting it includes all of them merged. That's useful for splitting source across folders, but it's also how unexpected CSS ends up on a page — someone adds a shared category to a new library and it starts loading everywhere.(The full section 6.3 answer. Anonymous can't read /apps; the proxy strips the prefix; it's environment-specific which is why it works on author; the {Boolean} hint; and the dispatcher as the second gate.)Because an author is authenticated and their user has read access to /apps, so the direct path works. A publish visitor is anonymous and doesn't, so the same reference 404s. That's why the bug only shows up after deployment, and why it's such a common ticket./etc.clientlibs is a proxy servlet that serves clientlib output without exposing /apps itself. The path is derived by stripping the leading /apps — so /apps/energy/clientlibs/clientlib-site is served as /etc.clientlibs/energy/clientlibs/clientlib-site.css. It works the same way for /libs. The proxy exposes only the generated CSS and JS plus the resources folder, not the source or anything else under /apps.dependencies says "load that other category before me, as a separate file" — so you get two requests with a guaranteed order, and it's transitive so AEM resolves the whole chain. embed says "take that other category's code and put it inside my generated file" — one request, one merged file. I use dependencies for a genuine ordering requirement like a plugin needing jQuery, and embed for the component clientlib pattern, where each component has a small clientlib for organisation and the page-level bundle embeds them all.No — and that's a good indicator you understand why the property exists. The browser never requests an embedded clientlib directly; its content is inside the bundle that is requested. So only the page-level bundles in our project have allowProxy, which cut the number of places we could get it wrong from about forty down to three.Duplication. If two bundles both embed the same library and a page loads both, that code ships and executes twice. For CSS it's usually just bloat, but for JavaScript that binds event handlers it causes real bugs — handlers fire twice. We manage it with a rule that each component clientlib is embedded by exactly one bundle.Different page policies. The page policy on each template defines which clientlib categories that page type loads, and the page component reads them from the resolved policy rather than hardcoding them. So both templates use the same page component but ship completely different bundles, with no code change. That's genuinely the main practical use of a page policy.Because the clientlib URL doesn't change between deployments, so browsers and the CDN keep serving the cached file — flushing the dispatcher doesn't help, since those caches are outside our control. The fix is putting a content hash in the URL so it changes whenever the content does. On Cloud Service that's built in; on 6.5 the standard answer is ACS Commons Versioned ClientLibs. It also lets you set a long TTL safely, which you can't really do without it.First I check whether the <link> tag is even in the page HTML. If it isn't, the category is wrong or the page policy has no clientlibs configured. If it is there, I check the network tab — if the URL 404s, the reference is fine and the fetch is failing, which means one of two things. I check dispatcher.log: if the request never reached AEM, the dispatcher filter isn't allowing /etc.clientlibs; if it did reach AEM and AEM returned 404, it's allowProxy. Beyond that, ?debugClientLibs=true shows me the individual unminified files so I can see exactly what's included and in what order, and the dumplibs pages show what a category actually resolves to.A webpack and npm module in the Maven build where the front-end code actually lives — SASS, TypeScript, modern tooling. The build compiles it and aem-clientlib-generator copies the output into a clientlib in ui.apps. The benefit is that front-end developers get their normal workflow and don't need a running AEM instance to work. The consequence to remember is that css.txt and js.txt are then generated, so editing them by hand gets overwritten on the next build.Measure first — Chrome DevTools has a Coverage tab showing exactly what proportion of each bundle executes on a given page, so I'm not guessing. Then the biggest win is usually splitting by page type using page policies, so a product page stops downloading the campaign JavaScript. Then move genuinely optional heavy things — a map library, a video player — to load on demand from the component that needs them rather than shipping up front. Then check for duplication from embed. On a project I worked on that took a typical page from around 400KB to roughly 120KB, and the ordering matters — the page-type split gave most of it.
- [Cloud Manager, Pipelines and CI/CD](https://nhanbe.id.vn/aem/advanced/cloud-manager-pipelines-and-ci-cd.md)
- [Code Quality, SonarQube and Best Practices](https://nhanbe.id.vn/aem/advanced/code-quality-sonarqube-and-best-practice.md)
- [AEM Component Development](https://nhanbe.id.vn/aem/advanced/component-development.md)
- [Content Fragments](https://nhanbe.id.vn/aem/advanced/content-fragments.md)
- [Core Components and the Style System](https://nhanbe.id.vn/aem/advanced/core-components-and-style-system.md)
- [Dialog Validation](https://nhanbe.id.vn/aem/advanced/dialog-validation.md)
- [Dispatcher, Caching and CDN](https://nhanbe.id.vn/aem/advanced/dispatcher-caching-and-cdn.md)
- [AEM Editable Templates and policies](https://nhanbe.id.vn/aem/advanced/editable-templates-and-policies.md): 1	What are editable templates?	Do you know they're content, not code 2	Where are they stored?	Have you actually looked in the repository 3	How are they created?	Have you built one, or only used them 4	What's the difference between structure and initial?	The main filter question 5	So if I change structure, what happens to existing pages?	Do you understand the live merge 6	What is a policy for?	Do you understand design-time vs content-time 7	Where are policies stored?	Do you know about the definition/mapping split 8	Page policy vs content policy?	Depth 9	How do you allow a component in a container?	Practical experience 10	How do you hide one?	Do you know there are three different meanings Two more threads that branch off: Thread B — from "structure changes are live" So how do existing pages know? → What is cq:template? → How does the merge work? → Why can't authors edit locked components? → How do you unlock one? → What property does that set? → Where is the content stored then? Thread C — from "policies control allowed components" Can two templates share a policy? → What happens if you edit a shared one? → How are they inherited across content? → What is sling:configRef? → Do nested containers inherit? → What if a nested container has no policy? The technique, same as always: answer in two sentences plus one example. A fuller answer absorbs the next question, so the thread runs out before you do. Best Interview Answers 6.1 "What are editable templates?" — about 90 seconds "Editable templates are templates stored as content under /conf rather than as code under /apps, which means a business user with template-author permissions can change them through a UI without a deployment. But the more important difference is that they stay live-linked to their pages. A page has a cq:template property pointing at its template, and at render time AEM merges the template's structure with the page's own content. So if I add a component to the structure, it appears on every existing page using that template immediately — no migration script. With static templates, the template only applied at page creation, so changing it did nothing to pages that already existed. A template has four parts. jcr:content holds its own properties like title and status. structure is what appears on every page and stays owned by the template. initial is the starting content copied into a new page once at creation. And policies maps each structure node to a policy definition. On our project we have around twelve of them — product category, product detail, news article, country landing and so on — and they ship as mutable content in our ui.content package with a merge filter so deployments don't overwrite template-author changes." 6.2 "Difference between structure and initial content?" — about 60 seconds This is the one to have word-perfect. "The simplest way to put it: structure is a live link, initial content is a photocopy. Structure defines what appears on every page using the template, and it stays owned by the template. It's merged into the page on every single render, which is why changing it updates all existing pages immediately. Initial content is just a starting point. At the moment a page is created, it's copied into that page's own jcr:content, and from then on the page owns it — there's no link back. So changing the initial content today affects only pages created from tomorrow. Existing pages never see it. Practically, I use structure for anything that must be on every page and stay consistent — our hero banner, breadcrumb and the contact block at the bottom of product pages. I use initial content for a helpful starting point the author is free to change or delete, like an empty text component so they're not staring at a blank page. And the follow-on that matters: if I'm asked to add something to 400 existing pages, the answer is structure. That's the single biggest advantage editable templates have." 6.3 "What is a policy and how do you define one?" — about 90 seconds "A policy is the design-time configuration for a component as used within a particular template. The most common use is the container policy that lists which components an author may add — but policies also control things like which rich-text options the Text component offers, allowed image widths, and the Style System classes an author can pick. The structure has two halves, and this is the part people find confusing. The policy definition holds the actual settings and lives centrally under /conf/<project>/settings/wcm/policies, at a path mirroring the component's resource type. The policy mapping lives inside the template, in a policies node that mirrors the structure tree, where each node has a cq:policy property pointing at a definition. The split exists for reuse — several templates can point at the same definition so I configure it once. The trade-off is that editing a shared definition changes every template using it, so I'm careful with naming and I separate definitions where the intent genuinely differs. To define one in practice, I select the component in the template editor, open its policy, either create a new one or pick an existing one, and configure it. For a container that means setting the allowed components — either individually by resource type, or by group with a group: prefix, which is what we do because it scales as we add components." Real Project Examples Story 1 — Adding a compliance block to every product page Requirement. A regulatory change meant every product page had to carry a standardised technical-compliance statement with a link to the relevant certification documents. Roughly 400 existing product pages, plus everything created afterwards. Why it's a good template story. The obvious approach — ask authors to add a component to 400 pages — was never realistic. It would take weeks and would be incomplete, which for a compliance requirement is a genuine risk. Approach. Added the component to the structure of the product category and product detail templates, positioned above the contact block. Because structure is merged on every render, all existing pages picked it up immediately with no content migration. The decisions that mattered. The statement text is identical across products, so we left the component locked — authors cannot accidentally delete or reword a compliance statement, which was exactly the point. But the certification document link differs by product family, so that one field came from context-aware configuration under /conf per product line, rather than being authored per page. The care taken. We made the change on stage first and reviewed a sample of pages including some with unusual layouts, because a structure change is live and global the moment it's saved — there's no staged rollout and no easy undo. And we shipped it as a ui.content package change through the pipeline rather than editing the template directly on production, so the change was reviewed and versioned. Result. All product pages compliant the same day, no author effort, and no way for the statement to be removed by accident. Story 2 — Splitting one over-permissive policy into three Requirement. Authors were putting the wrong components on the wrong page types — a campaign component on a technical product page, a product listing inside a news article. The cause. Every template's main container mapped to the same policy definition, and that policy allowed every component group. It had grown that way because each time someone needed a new component somewhere, it got added to the one shared policy. Approach. Split it into three definitions with clear titles — one for product pages, one for editorial and news pages, one for campaign pages — and remapped each template's cq:policy accordingly. Allowed lists were set by group rather than individual resource types, so adding a new component to a group automatically makes it available everywhere that group is allowed. The hard part. Working out what was actually in use before restricting anything. Removing a component from an allowed list does not delete it from pages that already have it — the component keeps rendering, authors just cannot add new ones. So we audited existing usage first to avoid a situation where a component is on live pages but nobody can add it to a new page. Result. Wrong-component tickets dropped substantially, and adding a new component became a matter of putting it in the right group rather than editing multiple policies. Story 3 — Making the hero editable without letting authors delete it Requirement. Every product page must have a hero banner — non-negotiable, it's the page's identity. But each page obviously needs its own headline, image and intro text. The tension. Locked structure components guarantee the hero is present but make it uneditable. Putting it in initial content makes it editable but lets authors delete it, and does nothing for existing pages. Approach. Put it in the structure and unlock it. The component is guaranteed on every page and cannot be deleted, but because editable="{Boolean}true" is set, its content lives on each page and each author sets their own. The detail that mattered. Because the hero renders on every page immediately, it rendered empty on pages nobody had filled in yet. So the component guards its outer element with data-sly-test and shows an authoring placeholder in edit mode — it renders nothing on publish rather than an empty banner, and shows a clickable placeholder to authors. Result. Structural guarantee and per-page content at the same time, and it became our default pattern for anything that must exist but must vary. Coding Examples Templates are content, so these are all repository XML. This is exactly what ships in ui.content. 8.1 The template's own properties ui.content/.../conf/energy/settings/wcm/templates/product-category-page/.content.xml <jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" jcr:primaryType="cq:Template"> <jcr:content jcr:primaryType="cq:PageContent" jcr:title="Product Category Page" jcr:description="Landing page for a product category, with sub-product cards and FAQ" status="enabled" ranking="{Long}10" allowedPaths="[/content/energy(/.*)?]"/> </jcr:root>Copy Copy Line by line, and what each one causes if you get it wrong: status="enabled" — leave this as draft and the template simply will not appear when authors create a page. This is the number one reason for "my template isn't showing up." allowedPaths — a regex array. /content/energy(/.*)? means "the /content/energy node itself, or anything below it." Get the regex wrong and the template is invisible in the Create Page dialog even though it is enabled. ranking — controls the order templates appear in. Small usability detail; authors notice. 8.2 The structure — locked and unlocked .../product-category-page/structure/.content.xml <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" jcr:primaryType="cq:Page"> <jcr:content jcr:primaryType="cq:PageContent" jcr:title="Product Category Page" sling:resourceType="energy/components/page" cq:template="/conf/energy/settings/wcm/templates/product-category-page"> </jcr:root>Copy Copy The one property to point at in an interview is editable="{Boolean}true" on the hero. That single property is the entire locked/unlocked mechanism. Without it, the hero renders identically on all 400 pages from the template. With it, the component is still guaranteed present but each page owns its content. 8.3 Initial content — the one-time copy .../product-category-page/initial/.content.xml <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" jcr:primaryType="cq:Page"> <jcr:content jcr:primaryType="cq:PageContent" sling:resourceType="energy/components/page" cq:template="/conf/energy/settings/wcm/templates/product-category-page"> <root jcr:primaryType="nt:unstructured" sling:resourceType="wcm/foundation/components/responsivegrid"> <container jcr:primaryType="nt:unstructured" sling:resourceType="wcm/foundation/components/responsivegrid"> </jcr:root>Copy Copy Notice that this tree mirrors the structure's shape — same root, same container — but only contains the starter components. It is dropped into the structure's containers at page creation. 8.4 The policy mapping — inside the template .../product-category-page/policies/.content.xml <jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" jcr:primaryType="cq:Page"> <jcr:content jcr:primaryType="nt:unstructured" </jcr:root>Copy Copy Three things to say about this file: It mirrors the structure tree — same node names, same nesting. That positional match is how AEM connects a structure node to its policy. The cq:policy on jcr:content itself is the page policy; the ones on child nodes are content policies. Same property, different level — which is exactly the answer to syllabus question 7. And each node needs its own cq:policy. There is no inheritance down this tree. 8.5 The policy definition — the actual settings ui.content/.../conf/energy/settings/wcm/policies/.content.xml (extract) <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" jcr:primaryType="nt:unstructured"> </jcr:root>Copy Copy The components property is the answer to "how do you allow a component." And notice the group: prefix — allowing by group means that when a developer adds a new component to the Energy - Content group, it becomes available everywhere that group is allowed, with no policy edit. That is the scaling decision, and it is worth calling out. 8.6 The page policy — different CSS per page type .../policies/energy/components/page/.content.xml (extract) <product_page_policy jcr:primaryType="nt:unstructured" jcr:title="Product Page Design" sling:resourceType="energy/components/page" clientlibs="[energy.base,energy.product]" clientlibsJsHead="[energy.base]"/>Copy Copy And the news template maps to a different one: <news_page_policy jcr:primaryType="nt:unstructured" jcr:title="News Page Design" sling:resourceType="energy/components/page" clientlibs="[energy.base,energy.editorial]"/>Copy Copy Same page component. Different clientlibs. No code change. That is the practical value of a page policy, and it is the example to give when asked what one is for. Full clientlib detail is in file 04. 8.7 The package filter that stops you destroying template changes ui.content/src/main/content/META-INF/vault/filter.xml Common Mistakes The mistake	What actually happens	The fix Template left as draft	Doesn't appear when authors create a page	Set status="enabled" allowedPaths regex wrong or missing	Template invisible in Create Page even though enabled	/content/energy(/.*)? style regex No mode="merge" on the /conf filter	Deployment wipes template-author changes	Add mode="merge" Putting templates in ui.apps	/conf is mutable content; breaks the immutable/mutable split	Ship in ui.content Expecting initial content changes to reach existing pages	They never will — it was a one-time copy	Use structure for that Editing structure on production casually	Live and global immediately, on every page	Change on lower envs, promote through the pipeline Nested container with no policy mapped	Authors can't add anything inside it	Give every container node its own cq:policy Editing a shared policy without checking usage	Silently changes every template pointing at it	Check usage; split definitions where intent differs Listing components individually instead of by group	Every new component needs a policy edit	Use group: prefix Locking a component that needs per-page content	Authors complain they can't edit it	Unlock it — editable="{Boolean}true" Unlocking a component and not handling the empty state	Renders as an empty box on every page until filled	data-sly-test guard plus an edit-mode placeholder Renaming or moving a structure node	Its policy mapping no longer matches, so the policy is lost	Update the mapping tree to match Assuming removing a component from a policy removes it from pages	It keeps rendering; authors just can't add new ones	Audit usage before restricting Confusing allowedPaths with cq:allowedTemplates	Wrong thing configured, template still missing	Template-side versus content-side — see 2.9Best Practices On template design. Keep the number of templates small — one per genuinely different page type, not one per visual variation. Visual variations belong to the Style System. If you find yourself creating "product page with sidebar" and "product page without sidebar," those should be one template plus a policy or style. On structure versus initial. Use structure for anything that must be present and consistent. Use initial content only as a helpful starting point. When in doubt, ask "would I want this on all existing pages if I added it tomorrow?" — if yes, it is structure. On locking. Lock by default; unlock deliberately. A locked component is a guarantee. Unlock only when the content genuinely varies per page, and when you do, handle the empty state. On policies. Allow by group, not by individual component, so adding a component doesn't mean editing policies. Give policies descriptive jcr:title values — "Product Page Container" tells the next person what it is for; "policy_1584032" does not. Split definitions where the intent differs, even if the settings happen to match today, because they will diverge. On governance. Template-author access on production is a business decision, not a technical one — but the safe default is no. Promote template changes through the pipeline as ui.content so they are reviewed and versioned like code. On packaging. Always mode="merge" on /conf and /content filters. Keep template types in your project so template authors start from the right skeleton. Debugging Tips When a template doesn't appear in Create Page, check these four in order — this ordering is the answer to a very common scenario question: Is status set to enabled, not draft? Does allowedPaths match the path where the author is creating the page? Is there a cq:allowedTemplates on that content folder's jcr:content restricting the list? Does the author's group have read access to the /conf folder holding the template? When authors can't add a component, check in this order: Does the container's policy list it — either directly or via its group? Is the component's own componentGroup empty or .hidden? Is it a nested container with no policy mapped at all? Does the author's group have modify permission on that path? When a component can't be edited on the page: it is almost certainly a locked structure component. Open the template in structure mode and check whether it is unlocked. When a policy seems to have no effect: open the template's policy mapping tree in CRXDE and compare it against the structure tree. If a structure node was renamed or moved, the mapping no longer lines up and the policy is silently lost. Useful paths for inspecting all this directly: /conf/<project>/settings/wcm/templates/<name>/structure/jcr:content → what appears on every page /conf/<project>/settings/wcm/templates/<name>/initial/jcr:content → what a new page starts with /conf/<project>/settings/wcm/templates/<name>/policies/jcr:content → the cq:policy mapping (compare against structure!) /conf/<project>/settings/wcm/policies/ → the actual policy definitions /content/.../mypage/jcr:content @ cq:template → which template this page is using /content/... @ sling:configRef → which /conf folder this content branch resolves configuration fromCopy Copy A quick diagnostic worth knowing: open a page's jcr:content in CRXDE and read cq:template. If it points at a template that no longer exists or was renamed, the page loses its structure entirely and renders bare. That is the explanation for "this page suddenly lost its header and footer." Performance Optimization Templates are not usually a performance problem, but three things are worth knowing: Structure is merged on every render. A very deep or very large structure means more merging work on every page request. Keep structures reasonably flat — this is one more reason not to build a template with dozens of locked components. Page policies control clientlibs, which is your real lever. Loading one giant site-wide CSS and JS bundle on every page type is the most common front-end performance mistake in AEM projects. Different page policies for different page types means product pages don't download the campaign JavaScript. This is genuinely the highest-impact thing on this page, and it lives in the page policy. Responsive grid configuration is set in Layout mode and stored as cq:responsive on the container. Getting breakpoints right at the template level avoids components doing their own ad-hoc responsive logic. Caching is unaffected — a page created from an editable template caches exactly like any other page. But note that a structure change invalidates nothing automatically. The template changed, but the dispatcher's cached pages did not. Existing cached pages keep serving the old structure until they are flushed. That is a genuinely good detail to raise: after a structure change, you need a cache flush, and on a large site that is a deliberate operation. Real Production ScenariosTemplate not appearing when creating a page. Check in order: status is draft; allowedPaths doesn't match; cq:allowedTemplates on the content folder; author lacks read on /conf.Author says they can't edit a component. Locked structure component. Unlock it in the template if it should be editable.Author can't add anything to a container. Policy doesn't allow it, or — if it's a nested container — no policy is mapped at all.Changed the template, existing pages didn't update. You changed initial content. Only structure reaches existing pages.Changed the template and broke 400 pages at once. You changed structure, which is live and global. Restore from a version of the /conf node, and move template edits off production.A component is on live pages but authors can't add new ones. It was removed from the policy's allowed list. Removing from a policy doesn't remove it from existing content.Editing one policy changed three templates. They share a policy definition. Split it if the intent differs.Deployment wiped the template changes. Missing mode="merge" on the /conf filter.A page suddenly lost its header and footer. Its cq:template points at a template that was renamed or deleted, so there is no structure to merge.Structure change made but the live site still shows the old layout. The dispatcher is serving cached pages. A structure change doesn't invalidate the cache — flush it.Two countries need different allowed components on the same template. Point each country's content branch at a different /conf folder via sling:configRef, so policies resolve differently per branch.A nested container lost its policy after a redesign. A structure node was renamed, so the policy mapping tree no longer matches by position. Update the mapping.Product pages loading campaign JavaScript. All templates share one page policy. Split them so each page type loads only its own clientlibs.Unlocked hero renders as an empty band on pages nobody has filled in. No empty-state guard. Add data-sly-test so it renders nothing on publish, plus an edit-mode placeholder.Authors report the component browser shows nothing at all. Usually the policy is missing entirely rather than restrictive — check that the container node has a cq:policy at all.Live copy pages don't reflect a template change. Check whether the live copy points at a different /conf via sling:configRef, resolving different policies. The structure itself should reach them via cq:template.Style System dropdown is empty for authors. cq:styleGroups isn't defined on that component's policy.Migrating a static template and pages render but look wrong. Design configuration from /etc/designs wasn't converted into policies.Template author changed something and nobody knows what. No versioning, because the change was made directly on production. This is the governance argument.allowedPaths works on one environment and not another. The regex includes an environment-specific path segment. Keep it generic to the site root.Follow-up Questions How many templates does your project have? Who has template-author access, and on which environments? Has a template change ever broken production? How do you promote a template change from dev to prod? How do you version template changes? Do you allow components individually or by group, and why? How many policies do you have, and are any shared across templates? Have you migrated static templates to editable ones? How do different page types load different clientlibs? What would you change about how your project manages templates? For that last one, a genuine answer: "I'd tighten the governance. We allow template-author access on staging, and a change there can be overwritten by the next deployment if someone forgets it isn't the source of truth. I'd rather all template changes originate in Git."Comparison Tables Static versus Editable templates — the table interviewers most often want Static template	Editable template Stored at	/apps/<project>/templates	/conf/<project>/settings/wcm/templates Code or content?	Code	Content Maven module	ui.apps (immutable)	ui.content (mutable) Who can edit	Developer only	Template author, through a UI Needs a deployment	Yes	No Connected to existing pages	No	Yes, via cq:template Structure change affects existing pages	No — needs a migration	Yes, immediately Design configuration	/etc/designs (legacy)	Policies Allowed components set by	cq:allowedTemplates, design config	Policy components property Responsive layout	Manual	Layout mode, cq:responsive Current recommendation	Legacy	Standard Structure versus Initial Content — the most-asked question Structure	Initial Content Purpose	What appears on every page	What a new page starts with Applied	On every render (live merge)	Once, at page creation Change affects existing pages	Yes, immediately	No, never Owned by	The template	The page, after creation Author can delete	No	Yes Author can edit	Only if unlocked	Yes Analogy	A live link	A photocopy Locked versus Unlocked structure components Locked (default)	Unlocked On every page	Yes	Yes Author can edit content	No	Yes Author can delete	No	No Content stored in	The template	Each page Property	(none)	editable="{Boolean}true" Use for	Breadcrumb, compliance block	Hero, page intro Page policy versus Content policy Page policy	Content policy Attached to	The page component (jcr:content)	A component inside the page Set via	Template editor → Page Design	Select component → policy icon Controls	Clientlib categories, page-level design	Allowed components, RTE options, styles Example	Product pages load energy.product	This container allows Energy - Content allowedPaths versus cq:allowedTemplates allowedPaths	cq:allowedTemplates Lives on	The template's jcr:content	A content folder's jcr:content Means	"I may be used under these paths"	"Only these templates here" Direction	Template → content	Content → template Where everything lives Thing	Path Editable templates	/conf/<project>/settings/wcm/templates Template types	/conf/<project>/settings/wcm/template-types Policy definitions	/conf/<project>/settings/wcm/policies Policy mappings	Inside each template, under policies/ Static templates (legacy)	/apps/<project>/templates Legacy design configs	/etc/designs 16. Memory Tricks Structure vs Initial: "Structure is a live link, initial is a photocopy." This one sentence answers the most-asked question in this topic. Structure vs Initial, second angle: "Structure = every page, forever. Initial = new pages, once." Where templates live: "Conf for content, apps for code." Editable templates are content, so /conf. The four template parts: "Properties, Structure, Initial, Policies" — P-S-I-P. Or: "what I am, what's always there, what you start with, what you're allowed." Policy split: "Definition lives central, mapping lives in the template." Locked vs unlocked: "Locked means the template owns it. Unlocked means the page owns it." Allowing components: "Group and policy — both must say yes." (Same rule as file 02.) Template not showing: "Draft or path." Status is draft, or allowedPaths doesn't match. Those two cover most cases. Nested containers: "Every container needs its own policy — nothing is inherited downward." Revision Notes Editable templates live at /conf/<project>/settings/wcm/templates. Content, not code. Ship in ui.content with mode="merge". Policies at /conf/<project>/settings/wcm/policies. Template types at /conf/<project>/settings/wcm/template-types. Static templates live at /apps/<project>/templates — code, legacy, no live link to pages. Four template parts: jcr:content (properties), structure, initial, policies. STRUCTURE = live, every page, changes reach existing pages immediately. INITIAL = copied once at page creation, changes never reach existing pages. Structure components are locked by default. Unlock = editable="{Boolean}true" → still on every page, but content lives per page. Page ↔ template link is cq:template on the page's jcr:content. At render time AEM merges template structure with page content. Policy = design-time configuration for a component within a template. Two halves: the definition (central, reusable, under /conf/.../policies) and the mapping (inside the template, mirrors the structure, cq:policy property). Page policy = on the page component; controls clientlibs and page-level design. Content policy = on a component inside the page; controls allowed components, RTE, styles. Allow a component = the components property on the container's policy. Use group: prefix to allow a whole component group. Hide a component has three meanings: remove from the policy list; componentGroup=".hidden"; or a data-sly-test in HTL. Nested containers do not inherit policies — each needs its own cq:policy. Template not showing → status is draft, or allowedPaths doesn't match, or cq:allowedTemplates restricts it. Structure change does not invalidate the dispatcher cache — flush it. Style System classes are defined in the policy as cq:styleGroups.Cheat Sheet Paths /conf/<project>/settings/wcm/templates/<name>/       the template ├── jcr:content        status, allowedPaths, jcr:title ├── structure/         every page, LIVE ├── initial/           new pages only, copied once └── policies/          cq:policy mapping (mirrors structure) /conf/<project>/settings/wcm/policies/               policy DEFINITIONS /conf/<project>/settings/wcm/template-types/         template blueprints /apps/<project>/templates/                           static templates (legacy) /etc/designs/                                        legacy design configsCopy Copy Template properties (jcr:content) jcr:title           name shown to authors status              draft | enabled | disabled allowedPaths        regex array, e.g. [/content/energy(/.*)?] ranking             order in the Create Page listCopy Copy Structure properties sling:resourceType  the page component cq:template         self-reference to the template editable="{Boolean}true"    UNLOCK a structure component cq:responsive       responsive grid breakpointsCopy Copy Policy properties cq:policy           on a mapping node → points at a definition components          allowed list: ["group:My Group", "proj/components/x"] cq:styleGroups      Style System class definitions clientlibs          on a PAGE policy → categories to load jcr:title           name it properly, not policy_1584032Copy Copy Content-side properties cq:template         on a page's jcr:content → its template cq:allowedTemplates on a folder's jcr:content → permitted templates below sling:configRef     which /conf folder this branch resolves config fromCopy Copy Package filter (ui.content) status = enabled?allowedPaths regex matches the creation path?cq:allowedTemplates on the content folder?author has read on /conf?Copy Copy Diagnostic checklist — can't add a componentIn the container policy's components list (directly or by group)?componentGroup empty or .hidden?Nested container with NO cq:policy mapped?Author has modify permission on the path?Copy CopyFrequently Forgotten Things Structure is live; initial content is a one-time copy. The most-asked question, and the easiest to state backwards under pressure. status="enabled" — a draft template never appears in Create Page. allowedPaths is a regex, not a plain path. mode="merge" on the /conf filter, or deployments wipe template changes. The policies folder inside a template contains pointers, not policies. The policy mapping mirrors the structure tree by position — rename a structure node and the policy is silently lost. Nested containers don't inherit policies. Unlocking sets editable="{Boolean}true" — the component is still structure, so it still cannot be deleted. cq:template lives on jcr:content, not on the page node. Removing a component from a policy doesn't remove it from existing pages — it just stops new ones being added. A structure change doesn't flush the dispatcher cache. allowedPaths is template-side; cq:allowedTemplates is content-side. Opposite directions. Editing a shared policy changes every template pointing at it. Page policies control clientlibs — that's how one page component serves different CSS per page type. Template types are created by developers, templates by template authors.Final Interview SummaryWhat they are. Templates stored as content under /conf, editable by a business user through a UI, and live-linked to their pages.Where they live. /conf/<project>/settings/wcm/templates, with policies and template-types as siblings under settings/wcm.The four parts. jcr:content properties, structure, initial, policies.Structure vs initial. Live link versus photocopy. Structure reaches existing pages immediately; initial content never does.Locked vs unlocked. Locked means the template owns the content; unlocked means each page does. editable="{Boolean}true".How rendering works. cq:template links the page to the template, and AEM merges structure with page content on every render — which is exactly why structure changes are instant.What a policy is. Design-time configuration for a component within a template. Definition central and reusable; mapping inside the template mirroring the structure.Page vs content policy. Same mechanism, two levels. Page policy controls clientlibs; content policy controls allowed components, RTE and styles.Allow and hide. The components property on the container policy, using group: prefixes. Both the component group and the policy must permit it.The risk. Structure changes are live, global and immediate, with no deployment gate — which is why template governance is a real conversation, not a technicality.Mock Interview How to use this: cover the answers, 25-minute timer, speak every answer out loud. The interviewer asks: What is an editable template and why did Adobe introduce them? Where are editable templates stored, and why there? How do you create one? Walk me through the steps. What are the parts of an editable template? What is the difference between structure and initial content? If I change the structure, what happens to 400 existing pages? If I change the initial content, what happens to those pages? Why does that difference exist — what's happening at render time? What is cq:template and where does it live? What is a locked component, and how do you unlock one? An author says they can't edit a component on the page. What are the possible causes? What is a policy and what is it used for? Where are policies stored? What's the difference between a policy definition and a policy mapping? What is the difference between a page policy and a content policy? How do you allow a component in a container? How do you hide one? Can two templates share a policy? What's the risk? Why can't authors add anything to my nested container? My template isn't appearing in the Create Page dialog. Debug it. Static versus editable templates — give me the full comparison. Model answers Templates stored as content under /conf rather than as code under /apps, so a business user with template-author permissions can edit them through a UI without a deployment. Adobe introduced them in 6.2 for two reasons: to remove the development bottleneck on structural changes, and — more importantly — because static templates only applied at page creation, so changing one did nothing to pages that already existed. Editable templates stay live-linked, so a structure change reaches every existing page immediately./conf/<project>/settings/wcm/templates. Policies are at /conf/<project>/settings/wcm/policies and template types at /conf/<project>/settings/wcm/template-types. They're in /conf because that's content, and /apps is code — especially on Cloud Service where /apps is immutable at runtime, so anything a business user edits couldn't live there. It also means templates are per-site, so different brands or regions can have different templates from one codebase.Tools → General → Templates, pick the configuration folder, click Create, choose a template type, name it. Then edit it in the template editor — Structure mode for what appears on every page, Initial Content for what a new page starts with, Layout for responsive breakpoints, and Page Design for the page policy. Then two steps people forget: set the status to Enabled, because a draft template won't appear when authors create a page, and set allowedPaths so it can only be used under the right content branch.Four children. jcr:content holds the template's own properties — title, status, allowedPaths. structure is the component tree that appears on every page and stays owned by the template. initial is the starting content copied into a new page at creation. And policies is a mapping tree that mirrors the structure and says which policy definition applies to which node — note that it contains pointers, not the policies themselves.Structure is a live link; initial content is a photocopy. Structure defines what appears on every page using the template and stays owned by the template — it's merged into the page on every render. Initial content is only a starting point: it's copied into the new page's own jcr:content at creation, and after that the page owns it with no link back.All 400 update immediately, with no migration. That's the single biggest advantage editable templates have over static ones. I'd be careful though — it's live and global the moment I save, so I'd make the change on a lower environment first and check a sample of pages, including ones with unusual layouts. And I'd remember that it doesn't flush the dispatcher cache, so cached pages keep serving the old structure until they're invalidated.Nothing. Existing pages are completely unaffected, because their copy was made at creation time and there's no link back to the template's initial node. Only pages created after the change get the new initial content.Because of how a page renders. The page's jcr:content has a cq:template property pointing at its template. On every render, AEM reads the template's structure and merges it with the page's own content — locked structure components render from the template, and anything the author owns renders from the page. Since that merge happens on every single render, structure is always current. Initial content isn't part of that merge at all; it was just a copy operation at creation.A property on the page's jcr:content — not on the page node itself — pointing at the template path. It's the live link that makes the structure merge possible. If it points at a template that's been renamed or deleted, the page loses its structure entirely and renders bare, which is the explanation for "this page suddenly lost its header and footer."Components placed in the structure are locked by default — they appear on every page and the content author can't select, edit or delete them, because the content lives in the template rather than on the page. Unlocking, done in the template editor's structure mode, sets editable="{Boolean}true". The component is still structure, so it's still guaranteed present and still can't be deleted, but its content now lives on each page so each author sets their own. We use that for the hero on product pages — every page must have one, but every page needs its own headline and image.Three possibilities, in order of likelihood. Most likely it's a locked structure component, placed by the template and deliberately not editable per page — the fix is unlocking it in the template. Second, the author's group might lack modify permission on that path. Third, though this affects adding rather than editing, the policy might not allow the component. With editable templates, the locked structure component is the answer the large majority of the time.A policy is the design-time configuration for a component as used within a particular template. The most common use is the container policy listing which components an author may add, but policies also control the rich-text options the Text component offers, allowed image widths, and the Style System classes an author can pick. The key phrase is "within a particular template" — the same container component can allow completely different components on the product template versus the news template.Definitions live at /conf/<project>/settings/wcm/policies, at a path mirroring the component's resource type. The mappings live inside each template under a policies node.The definition holds the actual settings and lives centrally so it can be shared. The mapping lives inside the template, mirrors the structure tree node for node, and each node has a cq:policy property pointing at a definition. The split exists for reuse — several templates can point at one definition so I configure it once. The trade-off is that editing a shared definition changes every template using it, which is a genuine source of surprise changes.Same mechanism at two levels. A content policy configures a component inside the page — the classic one being the container policy that lists allowed components. A page policy attaches to the page component itself and configures page-wide settings, most importantly which clientlib categories load. That's how our product pages and news pages use the same page component but load completely different CSS and JavaScript bundles, with no code change.To allow: set the components property on that container's policy. It takes either individual resource types or whole component groups with a group: prefix — we allow by group because then adding a new component to a group makes it available everywhere that group is allowed, with no policy edit. To hide, it depends what's meant. If it's "not available in this container," remove it from that policy's list. If it's "never available anywhere," set the component's own componentGroup to .hidden — that's what we do for helper components like accordion items. And if it's "on the page but shouldn't render," that's a data-sly-test in the HTL, nothing to do with templates. The thing that catches people out is that both the component group and the policy have to allow it — a component with a perfectly good group still won't appear if the policy doesn't list it. Yes, and that's the reason the definition and mapping are separate. The risk is that editing a shared definition silently changes every template pointing at it — someone adjusts the allowed components for product pages and inadvertently changes news pages too. I mitigate it by naming policies descriptively rather than leaving auto-generated names, and by splitting definitions where the intent differs even if the settings currently match, because they always diverge eventually.It has no policy mapped. Nested containers don't inherit their parent's policy — each container node in the template's policy mapping needs its own cq:policy. With no policy at all, the allowed list is empty, so the component browser shows nothing. I'd check by opening the template's policy mapping tree in CRXDE and comparing it node for node against the structure tree.Four checks in order. Is status set to enabled rather than draft — that's the most common cause. Does the allowedPaths regex actually match the path where the author is creating the page. Is there a cq:allowedTemplates property on that content folder's jcr:content restricting which templates are permitted there. And does the author's group have read access to the /conf folder holding the template. Those four cover essentially every case.(Give the full table from section 15. The two headline differences to lead with: where they live — /apps as code versus /conf as content — and whether they stay connected to existing pages. Then design configuration moving from /etc/designs to policies, who can edit them, and whether a deployment is needed.)
- [Experience Fragments](https://nhanbe.id.vn/aem/advanced/experience-fragments.md)
- [Headless AEM: GraphQL and the SPA Editor](https://nhanbe.id.vn/aem/advanced/headless-aem-graphql-and-spa-editor.md)
- [HTL (Slightly)](https://nhanbe.id.vn/aem/advanced/htl-slightly.md)
- [Java Fundamentals for AEM Developers](https://nhanbe.id.vn/aem/advanced/java-fundamentals-for-aem-developers.md)
- [JCR, Oak and the Repository](https://nhanbe.id.vn/aem/advanced/jcr-oak-and-the-repository.md)
- [Maven, Packages and the AEM Project Structure](https://nhanbe.id.vn/aem/advanced/maven-packages-and-project-structure.md)
- [MSM, Live Copies and Translation](https://nhanbe.id.vn/aem/advanced/msm-and-translation.md)
- [OSGi and Service](https://nhanbe.id.vn/aem/advanced/osgi-components-and-service.md)
- [Querying: QueryBuilder, JCR-SQL2 and Oak Indexes](https://nhanbe.id.vn/aem/advanced/querying-querybuilder-and-indexes.md)
- [Replication and Content Distribution](https://nhanbe.id.vn/aem/advanced/replication-and-distribution.md)
- [Resource Resolution and the Sling Resource Merger](https://nhanbe.id.vn/aem/advanced/resource-resolution-and-sling-resource-merger.md)
- [Scheduler, Sling Jobs and Event Handlers](https://nhanbe.id.vn/aem/advanced/schedulers-jobs-and-events.md)
- [Security Best Practices for AEM Developers](https://nhanbe.id.vn/aem/advanced/security-best-practices.md)
- [Sling Model Exporter](https://nhanbe.id.vn/aem/advanced/sling-model-exporter.md)
- [Sling Model](https://nhanbe.id.vn/aem/advanced/sling-model.md)
- [Sling Servlet](https://nhanbe.id.vn/aem/advanced/sling-servlet.md): /0200 { /type "allow" /path "/bin/energy/quote-request" /method "POST" }Copy Copy Note the rule is as narrow as possible — one exact path, one method. Allowing /bin/* for all methods would expose every path-bound servlet in the system, including ones you didn't write. 8.4 A Sling filter package com.energy.core.filters; import org.apache.sling.api.SlingHttpServletRequest; import org.apache.sling.api.SlingHttpServletResponse; import org.apache.sling.engine.EngineConstants; import org.apache.sling.servlets.annotations.SlingServletFilter; import org.apache.sling.servlets.annotations.SlingServletFilterScope; import org.osgi.service.component.annotations.Component; import org.osgi.service.component.propertytypes.ServiceRanking; import javax.servlet.*; import java.io.IOException; /** Adds security headers to every request.REQUEST scope = runs ONCE per request.COMPONENT scope would run for every component include, which forresponse headers would be pointless work repeated dozens of times. */ @Component(service = Filter.class) @SlingServletFilter(scope = SlingServletFilterScope.REQUEST) @ServiceRanking(-700)   // ordering relative to other filters public class SecurityHeadersFilter implements Filter {@Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { if (response instanceof SlingHttpServletResponse) { SlingHttpServletResponse slingResponse = (SlingHttpServletResponse) response; slingResponse.setHeader("X-Content-Type-Options", "nosniff"); slingResponse.setHeader("X-Frame-Options", "SAMEORIGIN"); slingResponse.setHeader("Referrer-Policy", "strict-origin-when-cross-origin"); } // Keep filters LIGHT -- this runs on every single request. chain.doFilter(request, response);}@Override public void init(FilterConfig config) { } @Override public void destroy() { } }Copy Copy 8.5 Unit testing a servlet package com.energy.core.servlets; import com.energy.core.services.ProductDataService; import io.wcm.testing.mock.aem.junit5.AemContext; import io.wcm.testing.mock.aem.junit5.AemContextExtension; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import org.mockito.Mockito; import static org.junit.jupiter.api.Assertions.*; @ExtendWith(AemContextExtension.class) class ProductSpecsServletTest { }Copy Copy Note what is being tested: the failure paths. Missing input, malformed input, the content type. Testing the happy path proves the least — it is the bad input and the error handling that break in production, and for a public endpoint the malformed-input test is the one a security reviewer will look for. Common Mistakes The mistake	What actually happens	The fix Path-bound servlet with no authorisation	Unauthenticated endpoint — anyone with the URL gets data	Register by resource type, or check permissions in code Path-bound servlet not whitelisted in the dispatcher	Works on author, 404 on publish	Add a narrow allow rule for that exact path and method /bin/* allowed broadly in the dispatcher	Exposes every path-bound servlet, including ones you didn't write	One rule per path, per method Resource-type servlet with no selector	Takes over the page render for that resource type	Always use a selector Query parameters instead of a selector or suffix	Response isn't dispatcher-cacheable	Selector + suffix Not clamping a value from the URL	Someone requests page 99999 and the server builds a huge list	Parse, validate the shape, clamp SlingAllMethodsServlet for a read-only servlet	Advertises methods you didn't implement; a review finding	SlingSafeMethodsServlet Closing request.getResourceResolver()	Breaks the rest of the request — you didn't open it	Only close resolvers you opened yourself Leaking a service-user resolver you opened	Session leak, eventually memory exhaustion	try-with-resources Returning a stack trace to the client	Leaks internal paths, class names, versions	Log the detail, return something generic Building JSON with string concatenation	Breaks on the first quote or apostrophe in the data	Jackson or another serialiser Not setting content type and encoding	Wrong rendering, mangled non-ASCII characters	Set both explicitly Always returning 200	Clients can't distinguish success from failure	201, 204, 400, 403, 404, 500 as appropriate Parsing the URL with substring	Breaks as soon as a selector or suffix appears	getRequestPathInfo() Heavy logic inside a filter	Runs on every single request, so the cost multiplies	Move it to a servlet or service Forgetting the servlet is an OSGi component	A missing @Reference gives a silent 404	Check /system/console/componentsBest Practices On registration. Default to resource type. Always include a selector so you don't shadow the page render. Use path binding only when there is genuinely no content context, and when you do, add the authorisation check and the dispatcher rule in the same change. On base classes. SlingSafeMethodsServlet unless it writes. That is free documentation and a smaller surface. On input. Everything from a URL or a form is untrusted. Validate by whitelisting the expected shape rather than blacklisting bad characters, and clamp anything numeric. On output. Set content type and encoding explicitly. Serialise with a library. Use meaningful status codes. Never return a stack trace. On resolvers. Never close the request's resolver. Always close one you opened yourself, with try-with-resources. Use a service user only when you genuinely need to read past the visitor's permissions, and check that the output doesn't leak what you just read. On structure. Keep servlets thin — parse the request, call a service, write the response. Business logic belongs in an OSGi service where it is reusable and testable. On caching. Decide cacheability before you write the endpoint. Selector and suffix if it should cache; accept that query parameters won't. On filters. Only for genuinely cross-cutting concerns, REQUEST scope unless you specifically need per-include behaviour, and keep them light. Debugging Tips The single most useful console for this topic is /system/console/servletresolver. You give it a URL and it tells you exactly which servlet or script will handle it — and which candidates it considered and rejected. That converts "why isn't my servlet called" from guesswork into one reading. The four-step checklist, in order: /system/console/servletresolver — what actually resolves for that URL? /system/console/components — is the servlet component Active or Unsatisfied? A missing @Reference gives a silent 404. Registration properties — do resource type, selector, extension and method all match? Dispatcher — if path-bound and only failing on publish, check dispatcher.log to see whether the request reached AEM at all. Reading the status code is a diagnostic in itself: Status	What it tells you 404	No servlet matched — or the component is unsatisfied, or the dispatcher blocked it 405	A servlet was found, but that HTTP method isn't implemented — wrong base class, or methods doesn't include it 403	Permission denied — the resource ACL, or your own check 500	Your code threw — check error.log 200 with an empty body	The servlet ran but wrote nothing — usually an early return without a status 404 versus 405 is the most useful distinction here. 405 means the resolution worked and only the method is wrong, which eliminates three of the four checks above immediately. Console	Answers /system/console/servletresolver	Which servlet handles this URL /system/console/components	Is the servlet component Active or Unsatisfied /system/console/services	Is it registered under javax.servlet.Servlet /system/console/slinglog	A DEBUG logger for just your servlet package dispatcher.log	Did the request even reach AEM Browser network tab	Status code, content type, response body 12. Performance Optimization Make it cacheable, and this dominates everything else. A resource-type servlet with a selector and suffix produces a path-based URL that the dispatcher caches as a file. The same endpoint with query parameters hits publish on every single request. On the Load More story that was the difference between a cached fragment and a page-tree traversal per click. Keep the servlet thin. Parse, delegate to a service, write. Logic in a service can be cached at the service layer and reused by models and other servlets. Never make a blocking external call without a timeout. Same rule as file 06 — a hung upstream consumes request threads until the instance stops responding. Clamp everything. Limits, page sizes, batch numbers. An unbounded value from a URL is how someone makes your server do arbitrary amounts of work. Return only what's needed. A JSON endpoint returning the full node tree when the client uses four fields wastes bandwidth and serialisation time. Set cache headers deliberately, so the CDN can cache too, not just the dispatcher. Keep filters minimal. A filter runs on every request, so a few milliseconds there is a few milliseconds on every page in the site. 2 sections hidden in Learn mode 13. Real Production Scenarios · 14. Follow-up Questions Show 15. Comparison Tables Path vs Resource Type — syllabus point 15 @SlingServletPaths	@SlingServletResourceTypes URL	Fixed, e.g. /bin/energy/x	Content path + selector Real resource behind it	No	Yes Content ACLs	Not applied	Applied automatically Authorisation	Your responsibility	Free Dispatcher	Must be whitelisted	Already allowed Cacheable	Rarely	Yes, with selector/suffix Needs content to exist	No	Yes Recommendation	Exception	Default SlingSafeMethodsServlet vs SlingAllMethodsServlet — syllabus point 16 Safe	All Methods	GET, HEAD, OPTIONS, TRACE	+ POST, PUT, DELETE Changes state	No	Yes Override	doGet, doHead	+ doPost, doPut, doDelete Relationship	—	Extends the safe one Use for	Read-only endpoints	Anything that writes HTTP methods Method	Purpose	Safe	Idempotent	Typical success status GET	Read	Yes	Yes	200 POST	Create / submit	No	No	201 or 202 PUT	Replace	No	Yes	200 or 204 DELETE	Remove	No	Yes	204 Servlet vs Filter vs Sling Model Sling Model	Servlet	Filter Runs when	A page renders	A URL is requested directly	Every request Purpose	Supply data to HTL	Handle a data request	Cross-cutting concerns Injection	@OSGiService	@Reference	@Reference Use for	Component logic	AJAX, form handlers, JSON	Headers, logging, redirects Selector vs Suffix vs Query parameter (from file 01, applied here) Selector	Suffix	Query param Example	.cards.	.html/2	?page=2 Part of the path	Yes	Yes	No Dispatcher-cacheable	Yes	Yes	No Read with	getSelectors()	getSuffix()	getParameter() Default servlets DefaultGetServlet	SlingPostServlet Handles	GET with no match	POST to a repository path Produces	.json, .html, .xml	Creates/updates nodes Known for	.infinity.json	Saving dialogs Security concern	Can dump content	Anyone with write access can create nodes 6 sections hidden in Learn mode 16. Memory Tricks · 17. Revision Notes · 18. Cheat Sheet · 19. Frequently Forgotten Things · 20. Final Interview Summary · 21. Mock Interview Show Next topic 08-HTL-Sightly — your syllabus points 17 and 18: how you call a Sling Model from HTL, every data-sly block element and what it's for, expression options and the display contexts, and why HTL deliberately can't do what JSP could.
- [System Design Basics for AEM Developers](https://nhanbe.id.vn/aem/advanced/system-design-basics-for-aem-developers.md)
- [Unit Testing: JUnit, Mockito and AEM Mocks](https://nhanbe.id.vn/aem/advanced/unit-testing-junit-mockito-and-aem-mocks.md)
- [Users, Groups, Roles and Permissions](https://nhanbe.id.vn/aem/advanced/users-groups-and-permissions.md)
- [Workflows](https://nhanbe.id.vn/aem/advanced/workflow.md)
- [AEMaaCS Introduction](https://nhanbe.id.vn/aem/aemaacs/aemaacs-introduction.md): Foundation about AEMaaCS
- [AEM Cheat Sheet](https://nhanbe.id.vn/aem/aem-cheatsheet.md): AEM developer quick reference cheatsheet covering common tasks, APIs, annotations, and commands.
- [AEM Maven Project archetype](https://nhanbe.id.vn/aem/maven-project-archetype.md): Command To Create Project Archetype
- [AEM APIs and Integrations Complete Guide](https://nhanbe.id.vn/others/posts/aem-apis-integrations-complete-guide.md): Complete guide on how AEM exposes and consumes REST and GraphQL APIs, authentication, and integration patterns.
- [AEM Architecture Complete Guide](https://nhanbe.id.vn/others/posts/aem-architecture-complete-guide.md): Production AEM architecture guide covering author, publish, Dispatcher, CDN, replication, and caching.
- [AEM Backend Development Complete Guide](https://nhanbe.id.vn/others/posts/aem-backend-development-complete-guide.md): End-to-end guide to AEM backend development covering components, templates, Sling Models, OSGi, servlets, and workflows.
- [AEM Dispatcher Complete Guide](https://nhanbe.id.vn/others/posts/aem-dispatcher-guide.md): Deep-dive guide to AEM Dispatcher caching, security filters, load balancing, and production configuration.
- [AEM GraphQL API and Persisted Queries Complete Guide](https://nhanbe.id.vn/others/posts/aem-graphql-api-persisted-queries-complete-guide.md): Guide to headless AEM GraphQL APIs, persisted queries, caching strategies, and performance optimization.
- [AEM Interview Cheatsheet & Preparation Guide](https://nhanbe.id.vn/others/posts/aem-interview.md): Comprehensive Adobe Experience Manager (AEM 6.5 & AEM Cloud Service) interview preparation guide covering architecture, Sling, OSGi, Oak JCR, Dispatcher, 57 interview Q&As, code examples, debugging, and production scenarios.
- [AEM JCR-SQL2 Recipe Book](https://nhanbe.id.vn/others/posts/aem-jcr-sql2-recipe-book.md): Production recipes and query optimization patterns for JCR-SQL2 in Jackrabbit Oak repository.
- [AEM Performance Troubleshooting Complete Guide](https://nhanbe.id.vn/others/posts/aem-performance-troubleshooting-complete-guide.md): Practical diagnostics and troubleshooting guide for AEM performance, thread dumps, heap dumps, GC logs, and memory leaks.
- [AEM SEO Complete Guide](https://nhanbe.id.vn/others/posts/aem-seo-complete-guide.md): Complete technical SEO guide for AEM covering sitemaps, robots.txt, canonical URLs, redirects, and metadata.
- [AEM Sling Dynamic Include (SDI) Guide](https://nhanbe.id.vn/others/posts/aem-sling-dynamic-includes-sdi-guide.md): Guide to Sling Dynamic Include (SDI) for caching dynamic components with SSI and ESI on AEM Dispatcher.
- [Unpublish Action in AEM](https://nhanbe.id.vn/others/posts/aem-unpublish-action.md)
- [Tích hợp Vuex vào AEM](https://nhanbe.id.vn/frontend/vue2.7/vuex/aem-integration.md): Integrating Vuex state management store into AEM frontend components.
- [SCSS trong AEM Clientlib](https://nhanbe.id.vn/frontend/scss/aem-clientlib-scss.md): Configuring SCSS compilation and Client Library organization in AEM frontend build.
- [Mở bundle-report.html để xem breakdown](https://nhanbe.id.vn/frontend/articles/aem-htl-vuejs-architecture-analysis.md): Architectural analysis for integrating Vue.js single page applications with AEM HTL components.

## Building for the Web

- [Building for the Web](https://nhanbe.id.vn/building-for-the-web/index.md): Principles, architecture, content modeling, web performance, and semantic HTML for modern web applications.
- [Color and Contrast](https://nhanbe.id.vn/building-for-the-web/web-content/color-and-contrast.md): WCAG contrast targets, color tokens, dark mode, and how to make links identifiable without relying on colour alone.
- [Forms and Interactions](https://nhanbe.id.vn/building-for-the-web/web-content/forms-and-interactions.md): Link text, navigation labels, form field labels, error messages, and mobile-first DOM order so users can act on the content you've structured.
- [Images and Media](https://nhanbe.id.vn/building-for-the-web/web-content/images-and-media.md): Meaningful alt text, decorative images, video controls, captions, and audio practices for accessible, scannable pages.
- [Information Architecture](https://nhanbe.id.vn/building-for-the-web/web-content/information-architecture.md): Site-level wayfinding - primary, utility, and footer navigation, breadcrumbs, taxonomies, search UX, and URL slug design that survive content growth.
- [Microcopy and Error States](https://nhanbe.id.vn/building-for-the-web/web-content/microcopy-and-error-states.md): How to write button labels, validation errors, empty states, loading states, success confirmations, and 404 pages so users always know what just happened and what to do next.
- [Website Content and Presentation](https://nhanbe.id.vn/building-for-the-web/web-content/overview.md): How to structure and write web content for readability, clear focus, solid UX, and accessible color and typography, with do and do-not examples in HTML, CSS, and copy.
- [Readability and Typography](https://nhanbe.id.vn/building-for-the-web/web-content/readability-and-typography.md): Plain language, defining jargon, microcopy basics, line measure, body type sizing, and responsive type that respects user defaults.
- [Structure and Hierarchy](https://nhanbe.id.vn/building-for-the-web/web-content/structure-and-hierarchy.md): Headings, landmarks, lists, page hierarchy, progressive disclosure, emphasis, calls to action, and whitespace - how to make a page scannable and focused.
- [Google Analytics](https://nhanbe.id.vn/building-for-the-web/analytics/google-analytics.md)
- [Web browser standard storage API](https://nhanbe.id.vn/building-for-the-web/web-api/standard-api.md)
- [All About web SEO](https://nhanbe.id.vn/building-for-the-web/web-seo/index.md)
- [Tích hợp Adobe Analytics, Target và Launch với AEM 6.5 On-Premise](https://nhanbe.id.vn/building-for-the-web/web-seo/adobe-analytics-target-launch-aem65.md): Giải thích vai trò và cách tích hợp Adobe Analytics, Adobe Target và Adobe Launch (Tags) vào ứng dụng AEM 6.5 on-premise.
- [RFC 9309: Robots Exclusion Protocol](https://nhanbe.id.vn/building-for-the-web/web-seo/robots-txt.md): Giải thích RFC 9309, cách parser robots.txt chọn User-agent và Allow/Disallow, cùng ví dụ triển khai an toàn cho website khách sạn.
- [Sitemap.xml cho website](https://nhanbe.id.vn/building-for-the-web/web-seo/sitemap-xml.md): Hướng dẫn tạo sitemap.xml đúng chuẩn, chọn URL cần khai báo và triển khai hiệu quả cho website, đặc biệt là website khách sạn.
- [EqualWeb](https://nhanbe.id.vn/building-for-the-web/equalweb-intro.md): Hướng dẫn kỹ thuật tích hợp EqualWeb widget: cấu hình window.interdeal, thiết lập CSP, tối ưu hiệu năng và đánh giá kỹ thuật dạng overlay.
- [Semantic HTML](https://nhanbe.id.vn/building-for-the-web/semantic-html.md): What semantic HTML is, why it matters, and a practical reference for every relevant element - document structure, text, lists, tables, forms, media, and interactive elements.
- [Web Performance](https://nhanbe.id.vn/building-for-the-web/web-performance.md): Core Web Vitals, Lighthouse, image and font optimization, caching strategies, code splitting, performance budgets, and common anti-patterns.

## AI

- [AI Notes](https://nhanbe.id.vn/ai/index.md): Notes on AI, LLMs, and coding assistant tools from a developer's perspective.
- [Obscura](https://nhanbe.id.vn/ai/obscura/index.md)
- [GitHub Copilot trong VS Code](https://nhanbe.id.vn/ai/github-copilot-vscode.md): Ghi chú cách dùng GitHub Copilot trong VS Code để đọc codebase, debug, review và giao việc cho agent.

## Others

- [Others & Tools](https://nhanbe.id.vn/others/index.md): Others & Tools A collection of cheatsheets, developer tools, and miscellaneous posts. Main sections - Cheatsheet - Posts - Tools
- [Fixing NPM Dependencies](https://nhanbe.id.vn/others/posts/security/fixing-npm-dependencies.md): How to fix NPM dependencies
- [Config GitHub Advanced Security for Azure DevOps](https://nhanbe.id.vn/others/posts/security/ghas-azure-devops.md): Fundamental concepts and setup steps for configuring GitHub Advanced Security in Azure DevOps.
- [ghas-redemiate](https://nhanbe.id.vn/others/posts/security/ghas-redemiate.md)
- [vapt](https://nhanbe.id.vn/others/posts/security/vapt.md)
- [ACS AEM Commons Guide](https://nhanbe.id.vn/others/posts/acs-aem-guide.md): Comprehensive guide to ACS AEM Commons architecture, components, features, and best practices.
- [Best Practices For Aem Developer](https://nhanbe.id.vn/others/posts/best-practices-for-aem-developer.md): Best practices for AEM 6.5 LTS developers covering architecture, security, performance, and coding standards.
- [Content Security Policy and Security Headers Guide](https://nhanbe.id.vn/others/posts/csp-security.md): Comprehensive guide to Content Security Policy (CSP) and modern HTTP security headers for AEM and web applications.
- [Migrate Moment.js sang Day.js](https://nhanbe.id.vn/others/posts/migrate-moment-to-dayjs.md): Migrate Moment.js sang Day.js - developer documentation and reference notes for Migrate Moment.js sang Day.js.
- [Testing an AEM 6.5 LTS Project](https://nhanbe.id.vn/others/posts/testing-aem-project.md): AemContext, Sling Model / OSGi service unit tests, JCR_OAK queries, UI tests, Dispatcher validation for AEM 6.5 LTS.
- [AEM Console Cheat Sheet](https://nhanbe.id.vn/others/cheatsheet/console_cheatsheet.md): Useful OSGi Felix Web Console and AEM system administration endpoints.
- [Dispatcher Cheat Sheet](https://nhanbe.id.vn/others/cheatsheet/dispatcher_cheatsheet.md): Dispatcher AEM - Apache
- [Git Command Cheatsheet](https://nhanbe.id.vn/others/cheatsheet/git-command.md): Ultimate Git Cheatsheet for Dev
- [1. Branch chinh, tach tu A của Release](https://nhanbe.id.vn/others/cheatsheet/git-note.md)
- [Groovy Console Snippets](https://nhanbe.id.vn/others/cheatsheet/groovy-script-snippet.md): All groovy scripts notes
- [CRX/DE & JCR — Debug Tips](https://nhanbe.id.vn/others/cheatsheet/jcr-note.md): Key concepts and reference notes for Java Content Repository (JCR) in AEM.
- [Problems & Solutions (AEM 6.5)](https://nhanbe.id.vn/others/cheatsheet/problems_solutions.md): Troubleshooting common AEM development errors and step-by-step solutions.
- [Query Builder Cheat Sheet](https://nhanbe.id.vn/others/cheatsheet/querybuilder_cheatsheet.md): Query Builder AEM cheatsheet
- [Adobe Experience Manager Links](https://nhanbe.id.vn/others/cheatsheet/README.md): AEM useful link
- [Image Detector Data Privacy](https://nhanbe.id.vn/others/tools/chrome-devtools-cheatsheet.md): Image Detector extension data privacy policy
- [Chrome DevTools: Frontend Debugging Playbook](https://nhanbe.id.vn/others/tools/chrome-devtools-debug.md): Playbook thực hành để debug DOM, CSS, JavaScript, Vue và bundle Webpack đã transpile hoặc minimize bằng Chrome DevTools.
- [CodeQL for AEM Projects](https://nhanbe.id.vn/others/tools/codeql-note.md): Guide to installing and running the latest CodeQL CLI on Windows for AEM multi-module projects.
- [Git Cheatsheet for Azure DevOps Workflow](https://nhanbe.id.vn/others/tools/devops-azure-git-note.md): Git workflow and CLI reference for Azure DevOps and AEM multi-project repositories
- [Firefox DevTools](https://nhanbe.id.vn/others/tools/firefox.md): 30+ tips & tricks for Firefox Developer Tools for web developers. Page Inspector, Console, Debugger, Network, RDM, and Storage.
- [Foam](https://nhanbe.id.vn/others/tools/foam.md): Setting up and using Foam as a personal knowledge management system in VS Code
- [GitHub Desktop](https://nhanbe.id.vn/others/tools/github-desktop.md): Tips and shortcuts for managing Git repositories using GitHub Desktop
- [JMeter](https://nhanbe.id.vn/others/tools/jmeter.md): Load testing and performance measurement guidelines using Apache JMeter
- [Notepad++](https://nhanbe.id.vn/others/tools/notepad-pp.md): Essential Notepad++ tips and features for working with AEM log files, XML, configurations, and scripts
- [Robots + Sitemap Inspector](https://nhanbe.id.vn/others/tools/robots-sitemap-inspector.md): Inspect robots.txt, sitemap, canonical, noindex, X-Robots-Tag and AI crawler rules (GPTBot, ClaudeBot...) for any domain.
- [Useful Link](https://nhanbe.id.vn/others/tools/useful-link.md): Useful resources and links
- [VS Code](https://nhanbe.id.vn/others/tools/vscode.md): Essential tips, shortcuts, and features in VS Code for AEM project development
- [Use Author CSS](https://nhanbe.id.vn/others/debug-draft/dom--container-disable-padding.md): How to properly configure AEM authoring client libraries
- [Cart null add-on items after login](https://nhanbe.id.vn/others/debug-draft/report.md)
- [ACL and Permission](https://nhanbe.id.vn/others/acl-and-permissions.md): AEM's permission model is built on **Jackrabbit Oak's access control*layer. Every read, write, and delete operation on the JCR is governed by
- [AEM Permissions & ACL 101](https://nhanbe.id.vn/others/permissions-101.md): Beginner guide to AEM permissions, group inheritance, and ACL evaluation.
- [Useful links, resoures for dev.](https://nhanbe.id.vn/others/useful-resource.md)
- [Vue Component Integration in AEM](https://nhanbe.id.vn/others/vuejs-aem-intergration.md): How a server-side AEM (HTL) component hands data to a client-side Vue 2.7 component, and how Vue components compose with each other once mounted

## All Notes

- [All Notes](https://nhanbe.id.vn/notes.md)

## Blog

- [Blog](https://nhanbe.id.vn/blog/index.md): Blog Notes, experiences, and articles from my AEM learning journey. Posts - Welcome — 2021-08-26
- [Business operation largoon of Hospitality](https://nhanbe.id.vn/blog/hospitality/basic-hospitality.md): learn about Hospitality business term for developer
- [Welcome](https://nhanbe.id.vn/blog/welcome/index.md): Welcome - developer documentation and reference notes for Welcome.
- [Giao tiếp công sở: nhận diện điểm mù và nâng cao hiệu quả](https://nhanbe.id.vn/blog/giao-tiep-cong-so-va-diem-mu.md): Tóm lược các ý chính về Johari Window, Dunning–Kruger effect và cách cải thiện giao tiếp trong công việc.
- [Tăng cường bảo mật AEM 6.5 với Azure Key Vault](https://nhanbe.id.vn/blog/integrate-azure-key-vault-in-aem.md): Hướng dẫn tích hợp Azure Key Vault vào AEM 6.5 on-premise, xác thực bằng Azure CLI ở môi trường local và Client Certificate qua Keystore trên production.
- [8 lời khuyên phát triển sự nghiệp cho kỹ sư phần mềm](https://nhanbe.id.vn/blog/loi-khuyen-phat-trien-su-nghiep-ky-su-phan-mem.md): Tóm lược những bài học về giá trị nghề nghiệp, ảnh hưởng, lãnh đạo và phát triển bản thân dành cho kỹ sư phần mềm.

## Others

- [Introduction & First Styles](https://nhanbe.id.vn/css/beginners-guide/01-introduction.md): What CSS is, how it works with HTML, the three ways to add styles, the anatomy of a CSS rule, writing your first stylesheet, and a quick look at browser DevTools.
- [Selectors](https://nhanbe.id.vn/css/beginners-guide/02-selectors.md): How CSS targets HTML elements - element, class, ID, universal, grouping, descendant, child, sibling, and attribute selectors.
- [The Box Model](https://nhanbe.id.vn/css/beginners-guide/03-the-box-model.md): How browsers calculate element sizes using the CSS box model - content, padding, border, margin, box-sizing, and debugging with DevTools.
- [Colors & Typography](https://nhanbe.id.vn/css/beginners-guide/04-colors-and-typography.md): CSS colour formats (named, hex, rgb, hsl), opacity, font properties, text styling, web-safe fonts, and loading Google Fonts.
- [Units & Sizing](https://nhanbe.id.vn/css/beginners-guide/05-units-and-sizing.md): CSS length units - px, em, rem, percentages, viewport units, and when to use each one for font sizes, spacing, and layout.
- [Display & Positioning](https://nhanbe.id.vn/css/beginners-guide/06-display-and-positioning.md): How CSS display modes (block, inline, inline-block) and positioning (static, relative, absolute, fixed, sticky) control element flow and placement.
- [Flexbox](https://nhanbe.id.vn/css/beginners-guide/07-flexbox.md): CSS Flexbox layout - flex containers and items, direction, wrapping, alignment, sizing with flex-grow/shrink/basis, gap, and common patterns.
- [CSS Grid](https://nhanbe.id.vn/css/beginners-guide/08-css-grid.md): CSS Grid layout - defining rows and columns, the fr unit, grid areas, gap, auto-fit/auto-fill, minmax(), and implicit vs explicit grids.
- [Responsive Design](https://nhanbe.id.vn/css/beginners-guide/09-responsive-design.md): Building layouts that work on every screen size - the viewport meta tag, media queries, mobile-first development, breakpoints, responsive images, and fluid typography.
- [Backgrounds, Borders & Shadows](https://nhanbe.id.vn/css/beginners-guide/10-backgrounds-borders-shadows.md): CSS background images, gradients, background shorthand, border-radius for rounded corners, box-shadow, text-shadow, and multiple backgrounds.
- [Transitions & Animations](https://nhanbe.id.vn/css/beginners-guide/11-transitions-and-animations.md): CSS transitions for smooth state changes, transform functions (translate, rotate, scale, skew), keyframe animations, timing functions, and performance tips.
- [Pseudo-classes & Pseudo-elements](https://nhanbe.id.vn/css/beginners-guide/12-pseudo-classes-and-pseudo-elements.md): CSS pseudo-classes for targeting element states (:hover, :focus, :nth-child) and pseudo-elements for creating virtual content (::before, ::after).
- [CSS Custom Properties](https://nhanbe.id.vn/css/beginners-guide/13-css-custom-properties.md): CSS custom properties (variables) - defining, using, scoping, fallback values, theming, building a dark mode toggle, and dynamic updates with JavaScript.
- [Specificity & the Cascade](https://nhanbe.id.vn/css/beginners-guide/14-specificity-and-the-cascade.md): How CSS decides which rule wins - the cascade algorithm, specificity calculation, inheritance, the !important keyword, and cascade layers.
- [Modern CSS Features](https://nhanbe.id.vn/css/beginners-guide/15-modern-css-features.md): Recent CSS additions - native nesting, the :has() selector, container queries, @layer, logical properties, color-mix(), accent-color, and subgrid.
- [Architecture & Best Practices](https://nhanbe.id.vn/css/beginners-guide/16-architecture-and-best-practices.md): Organising CSS for maintainability - BEM naming, file structure, CSS resets vs normalisers, utility classes, component-scoped styles, and preprocessor overview.
- [Debugging & Common Pitfalls](https://nhanbe.id.vn/css/beginners-guide/17-debugging-and-common-pitfalls.md): Using browser DevTools to debug CSS, understanding margin collapse, overflow issues, centring gotchas, z-index problems, and cross-browser testing.
- [Practice Projects](https://nhanbe.id.vn/css/beginners-guide/18-practice-projects.md): Six hands-on CSS projects from beginner to advanced - personal profile card, navigation bar, photo gallery, landing page, dashboard layout, and CSS art.
- [CSS Container Queries](https://nhanbe.id.vn/css/container-queries.md): Make components respond to their own slot size with CSS container queries. Interactive demos, the core API, and when to prefer them over media queries or device width.
- [CSS Notes](https://nhanbe.id.vn/css/index.md): Practical CSS notes covering modern layouts, responsive design, container queries, custom properties, and styling best practices.
- [Anti-Patterns and Misuse](https://nhanbe.id.vn/design-patterns/anti-patterns.md): Patterns are tools, not goals. These are common misuses that reduce clarity and maintainability. Singletons introduce global state and hidden
- [Chain of Responsibility](https://nhanbe.id.vn/design-patterns/behavioral/chain-of-responsibility.md): Pass a request along a chain of handlers until one handles it. Multiple handlers can process a request. You want to decouple sender from receiver
- [Command](https://nhanbe.id.vn/design-patterns/behavioral/command.md): Encapsulate a request as an object, allowing parameterization and queuing. You need undo/redo. You want to queue or log operations. Pros: Suppor
- [Interpreter](https://nhanbe.id.vn/design-patterns/behavioral/interpreter.md): Define a grammar and an interpreter to evaluate expressions in that language. You need a small, stable language for rules or filters. Expression
- [Iterator](https://nhanbe.id.vn/design-patterns/behavioral/iterator.md): Provide a way to access elements of a collection sequentially without exposing its representation. You want consistent traversal across differen
- [Mediator](https://nhanbe.id.vn/design-patterns/behavioral/mediator.md): Define an object that centralizes communication between other objects. Many objects communicate in complex ways. You want to reduce direc
- [Memento](https://nhanbe.id.vn/design-patterns/behavioral/memento.md): Capture and externalize an object's internal state so it can be restored later. You need undo/redo. You want to keep state history without exposing
- [Observer](https://nhanbe.id.vn/design-patterns/behavioral/observer.md): Define a one-to-many dependency so that when one object changes state, all dependents are notified. You need event-driven updates. Multiple
- [State](https://nhanbe.id.vn/design-patterns/behavioral/state.md): Allow an object to alter its behavior when its internal state changes. Behavior varies based on state. You want to avoid large conditionals. Pros:
- [Strategy](https://nhanbe.id.vn/design-patterns/behavioral/strategy.md): Define a family of algorithms and make them interchangeable. You need runtime selection of behavior. You want to avoid large switch statemen
- [Template Method](https://nhanbe.id.vn/design-patterns/behavioral/template-method.md): Define the skeleton of an algorithm and let subclasses override specific steps. You want consistent flow with variable steps. You need shared
- [Visitor](https://nhanbe.id.vn/design-patterns/behavioral/visitor.md): Add operations to object structures without changing their classes. You need to run multiple operations on a stable object structure. Adding new
- [Abstract Factory](https://nhanbe.id.vn/design-patterns/creational/abstract-factory.md): Provide an interface for creating families of related objects without specifying their concrete classes. You need consistent object families (for
- [Builder](https://nhanbe.id.vn/design-patterns/creational/builder.md): Separate the construction of a complex object from its representation. You need to build objects step by step. You want readable, fluent creation
- [Factory Method](https://nhanbe.id.vn/design-patterns/creational/factory-method.md): Define an interface for creating objects, but let subclasses decide which class to instantiate. The exact concrete type is decided at runtime. You
- [Prototype](https://nhanbe.id.vn/design-patterns/creational/prototype.md): Create new objects by copying an existing instance (the prototype). Object creation is expensive or complex. You need many similar instances with
- [Singleton](https://nhanbe.id.vn/design-patterns/creational/singleton.md): Ensure a class has a single instance and provide a global access point to it. A single shared resource is required (for example, config, cache). You
- [Glossary](https://nhanbe.id.vn/design-patterns/glossary.md): An interface or base type that hides implementation details. How strongly related the responsibilities of a module are. High cohesion is preferred
- [Design Patterns](https://nhanbe.id.vn/design-patterns/index.md): Comprehensive reference for object-oriented design patterns, creational, structural, and behavioral patterns.
- [Overview](https://nhanbe.id.vn/design-patterns/overview.md): This section collects GoF patterns with practical examples and guidance. Use it to pick a suitable pattern, not to force one. **Object creation i
- [Adapter](https://nhanbe.id.vn/design-patterns/structural/adapter.md): Convert the interface of a class into another interface clients expect. You need to integrate a legacy or third-party API. You want to reuse
- [Bridge](https://nhanbe.id.vn/design-patterns/structural/bridge.md): Decouple an abstraction from its implementation so both can vary independently. You need to support multiple implementations across multiple
- [Composite](https://nhanbe.id.vn/design-patterns/structural/composite.md): Compose objects into tree structures and treat individual objects and composites uniformly. You need to represent part-whole hierarchies. Clien
- [Decorator](https://nhanbe.id.vn/design-patterns/structural/decorator.md): Attach additional responsibilities to an object dynamically by wrapping it. You need flexible, runtime composition of behavior. Inheritance would
- [Facade](https://nhanbe.id.vn/design-patterns/structural/facade.md): Provide a simplified interface to a complex subsystem. You want a clean API for a complex set of classes. You want to decouple clients from
- [Flyweight](https://nhanbe.id.vn/design-patterns/structural/flyweight.md): Share common state between many objects to reduce memory usage. You have many similar objects with small variations. Memory usage is a concern
- [Proxy](https://nhanbe.id.vn/design-patterns/structural/proxy.md): Provide a placeholder or surrogate to control access to another object. You want lazy loading or caching. You need access control or logging. Pros:
- [Introduction to Docker](https://nhanbe.id.vn/docker/beginners-guide/01-introduction.md): Learn what Docker is, how containers differ from virtual machines, and how to install and verify Docker on your system.
- [Images and Containers](https://nhanbe.id.vn/docker/beginners-guide/02-images-and-containers.md): Learn how to pull images, run containers with essential flags, manage container lifecycle, and clean up your local environment.
- [Writing a Dockerfile](https://nhanbe.id.vn/docker/beginners-guide/03-dockerfile.md): Learn how to write a Dockerfile to build custom images, understand layer caching, use .dockerignore, and tag and push your builds.
- [Volumes and Bind Mounts](https://nhanbe.id.vn/docker/beginners-guide/04-volumes-and-bind-mounts.md): Understand named volumes and bind mounts, when to use each, and how to persist data across container restarts and rebuilds.
- [Docker Networking](https://nhanbe.id.vn/docker/beginners-guide/05-networking.md): Learn how Docker networks work, how containers communicate with each other by name, and how port mapping exposes services to the host.
- [Docker Compose](https://nhanbe.id.vn/docker/beginners-guide/06-docker-compose.md): Learn how to define and manage multi-container applications with Docker Compose, covering services, volumes, networks, and a full worked example.
- [Multi-Stage Builds](https://nhanbe.id.vn/docker/beginners-guide/07-multi-stage-builds.md): Learn how to use multi-stage builds to produce small, secure production images by separating build-time and runtime dependencies.
- [Environment Variables and Secrets](https://nhanbe.id.vn/docker/beginners-guide/08-environment-and-secrets.md): Learn how to manage configuration and secrets in Docker using ENV, ARG, .env files, runtime injection, and Docker secrets - without baking sensitive data into images.
- [Registries and Image Management](https://nhanbe.id.vn/docker/beginners-guide/09-registries-and-images.md): Learn how to push and pull images to Docker Hub, GHCR, and private registries, apply tagging conventions, and scan images for vulnerabilities.
- [Health Checks and Logging](https://nhanbe.id.vn/docker/beginners-guide/10-health-checks-and-logging.md): Learn how to configure Docker health checks, inspect container health status, manage logs with docker logs, and choose the right log driver for production.
- [Docker in CI/CD](https://nhanbe.id.vn/docker/beginners-guide/11-docker-in-ci-cd.md): Learn how to build and push Docker images in GitHub Actions, cache layers for faster CI builds, and deploy by pulling and restarting containers.
- [Production Best Practices](https://nhanbe.id.vn/docker/beginners-guide/12-production-best-practices.md): Getting a container to run is the easy part. Getting it to run **safely and reliably in production*requires discipline across several dimensions:
- [Docker Notes](https://nhanbe.id.vn/docker/index.md): Practical guides and reference notes for containerization, Dockerfile best practices, and Docker Compose workflows.
- [MVVM](https://nhanbe.id.vn/frontend/articles/mvvm.md): Understanding MVVM design pattern principles and implementation in web frontend applications.
- [VS Code HTL Snippets](https://nhanbe.id.vn/frontend/articles/vscode-htl-snippet.md): Useful VSCode code snippets for fast HTL HTML template language development in AEM.
- [Tích hợp Vue 2 vào AEM 6.5 Maven Archetype](https://nhanbe.id.vn/frontend/articles/vue2-aem65-integration.md): Complete guide for integrating Vue.js 2.7 components with AEM 6.5 Touch UI.
- [Vue 2 + AEM 6.5 Handbook — Phần 1: Core Features](https://nhanbe.id.vn/frontend/articles/vuejs-aem-handbook-part1.md): AEM and Vue.js integration handbook part 1: project setup and component architecture.
- [Vue 2 + AEM 6.5 Handbook — Phần 2: AEM Features & Advanced Patterns](https://nhanbe.id.vn/frontend/articles/vuejs-aem-handbook-part2.md): AEM and Vue.js integration handbook part 2: state management, dynamic loading, and build deployment.
- [Frontend Development](https://nhanbe.id.vn/frontend/index.md): A collection of frontend notes and articles covering the AEM and Vue.js ecosystem. [Vue 2.7](./vue2.7/introduction) [SCSS](./scss/introduction)
- [Control Flow & Maps](https://nhanbe.id.vn/frontend/scss/control-flow-maps.md): Using Sass SCSS control flow directives, loops, and map data structures.
- [Extend & Placeholders](https://nhanbe.id.vn/frontend/scss/extend-placeholders.md): Sass SCSS extend directive and placeholder selectors best practices.
- [SCSS Introduction](https://nhanbe.id.vn/frontend/scss/introduction.md): SCSS Introduction - developer documentation and reference notes for SCSS Introduction.
- [Mixins & Functions](https://nhanbe.id.vn/frontend/scss/mixins-functions.md): Authoring reusable Sass SCSS mixins and custom functions.
- [Partials & Modules](https://nhanbe.id.vn/frontend/scss/partials-modules.md): Structuring Sass SCSS partial files and module imports with @use and @forward.
- [Variables & Nesting](https://nhanbe.id.vn/frontend/scss/variables-nesting.md): Sass SCSS variables scoping, selector nesting rules, and clean code practices.
- [Class Style Biding](https://nhanbe.id.vn/frontend/vue2.7/class-style-biding.md): Vue 2.7 class and inline style binding syntax and patterns.
- [Component Registration](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/component-registration.md): Global and local component registration in Vue 2.7 applications.
- [Components Basics](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/components-basics.md): Fundamentals of Vue 2.7 component hierarchy, props, and data flow.
- [Custom Events](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/custom-events.md): Handling component v-model and custom events in Vue 2.7.
- [Dynamic & Async Components](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/dynamic-async-components.md): Working with dynamic components and asynchronous module loading in Vue 2.7.
- [Handling Edge Cases](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/handling-edge-cases.md): Handling edge cases, recursive components, and inline templates in Vue 2.7.
- [Props](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/props.md): Vue 2.7 component props declaration, validation, and immutability.
- [Slots](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/slots.md): Using default, named, and scoped slots for component composition in Vue 2.7.
- [Vue Instance](https://nhanbe.id.vn/frontend/vue2.7/component-in-depth/vue-instance.md): Vue Instance - developer documentation and reference notes for Vue Instance.
- [Computed Methods and Watch](https://nhanbe.id.vn/frontend/vue2.7/computed-methods-and-watch.md): Comparing computed properties, methods, and watchers in Vue 2.7.
- [Conditional Rendering](https://nhanbe.id.vn/frontend/vue2.7/conditional-rendering.md): Vue 2.7 v-if, v-else-if, v-else, and v-show conditional rendering directives.
- [Event Handling](https://nhanbe.id.vn/frontend/vue2.7/event-handling.md): Listening to DOM events, inline handlers, and event modifiers in Vue 2.7.
- [Form Input Binding](https://nhanbe.id.vn/frontend/vue2.7/form-input-binding.md): Working with two-way data binding and form inputs using v-model in Vue 2.7.
- [Installation](https://nhanbe.id.vn/frontend/vue2.7/installation.md): create vite Vue cli Vue 2.7 - create vue project Vite main.js - package.json - install
- [Vue Instance](https://nhanbe.id.vn/frontend/vue2.7/instance.md): Understanding the Vue 2.7 instance lifecycle, reactive state, and options.
- [Giới thiệu Vue 2](https://nhanbe.id.vn/frontend/vue2.7/introduction.md): Introduction to Vue 2.7 features, Composition API backport, and core framework syntax.
- [List Rendering](https://nhanbe.id.vn/frontend/vue2.7/list-rendering.md): Rendering lists with v-for directive, key binding, and array mutation detection in Vue 2.7.
- [Template](https://nhanbe.id.vn/frontend/vue2.7/template.md): Vue 2.7 template syntax, interpolation, and directive expressions.
- [Actions](https://nhanbe.id.vn/frontend/vue2.7/vuex/actions.md): Managing asynchronous business logic with Vuex actions.
- [Vuex Introduction](https://nhanbe.id.vn/frontend/vue2.7/vuex/introduction.md): Vuex Introduction - developer documentation and reference notes for Vuex Introduction.
- [Modules](https://nhanbe.id.vn/frontend/vue2.7/vuex/modules.md): Organizing large Vuex stores with namespaced modules.
- [Mutations](https://nhanbe.id.vn/frontend/vue2.7/vuex/mutations.md): Committing synchronous state mutations in Vuex store.
- [State & Getters](https://nhanbe.id.vn/frontend/vue2.7/vuex/state-getters.md): Defining reactive state properties and computed getters in Vuex.
- [Introduction](https://nhanbe.id.vn/intro.md): Introduction to the AEM and frontend notes by Nhan.
- [Java Interview Question](https://nhanbe.id.vn/java/articles/java-interview-question.md)
- [Introduction & Environment Setup](https://nhanbe.id.vn/java/beginners-guide/01-introduction.md): What Java is, how the JDK/JRE/JVM relate, installing the JDK, compiling and running your first program, and choosing an IDE.
- [Variables, Types & Operators](https://nhanbe.id.vn/java/beginners-guide/02-variables-and-types.md): Learn Java's primitive types, String basics, type casting, var, final, arithmetic, comparison, and logical operators.
- [Control Flow](https://nhanbe.id.vn/java/beginners-guide/03-control-flow.md): Learn Java control flow - if/else, switch expressions, for/while/do-while loops, enhanced for-each, break, continue, and common patterns.
- [Methods](https://nhanbe.id.vn/java/beginners-guide/04-methods.md): Learn Java methods - defining and calling static methods, parameters, return types, overloading, varargs, scope, and recursion.
- [Classes & Objects](https://nhanbe.id.vn/java/beginners-guide/05-classes-and-objects.md): Learn Java OOP basics - classes, objects, constructors, access modifiers, encapsulation, toString, equals/hashCode, static members, and records.
- [Inheritance & Interfaces](https://nhanbe.id.vn/java/beginners-guide/06-inheritance-and-interfaces.md): Learn Java inheritance, method overriding, abstract classes, interfaces, polymorphism, sealed classes, and composition vs inheritance.
- [Collections](https://nhanbe.id.vn/java/beginners-guide/07-collections.md): Learn Java collections - ArrayList, HashMap, HashSet, iterating, generics, immutable collections, and choosing the right collection.
- [Error Handling](https://nhanbe.id.vn/java/beginners-guide/08-error-handling.md): Learn Java error handling - try/catch/finally, checked vs unchecked exceptions, custom exceptions, try-with-resources, and best practices.
- [File I/O](https://nhanbe.id.vn/java/beginners-guide/09-file-io.md): Learn Java file I/O - Path, Files, reading and writing text files, directories, BufferedReader/Writer, and simple CSV parsing.
- [Project: CLI Task Manager](https://nhanbe.id.vn/java/beginners-guide/10-project-cli-task-manager.md): Build a complete command-line task manager in Java - CRUD operations, file-based persistence, input validation, and packaging as a runnable JAR.
- [Building a REST API](https://nhanbe.id.vn/java/beginners-guide/11-rest-api.md): Build a REST API with Java's built-in HttpServer - HTTP basics, request handling, JSON serialization, routing, and exposing the task manager over HTTP.
- [Deploying to a VPS with Nginx](https://nhanbe.id.vn/java/beginners-guide/12-deploy-vps-nginx.md): Deploy your Java REST API to a VPS - installing the JDK, running as a systemd service, configuring nginx as a reverse proxy, and HTTPS with Let's Encrypt.
- [Maven](https://nhanbe.id.vn/java/beginners-guide/13-maven.md): Learn Apache Maven - project structure, dependency management, building fat JARs, and improving the REST API project with Gson for JSON handling.
- [Gradle](https://nhanbe.id.vn/java/beginners-guide/14-gradle.md): Learn Gradle with Kotlin DSL - project structure, dependency management, building fat JARs, and improving the REST API project with Jackson for JSON handling.
- [Streams & Lambdas](https://nhanbe.id.vn/java/beginners-guide/15-streams-and-lambdas.md): Functional Java - lambda expressions, method references, the Stream API, and practical data processing pipelines.
- [Optionals](https://nhanbe.id.vn/java/beginners-guide/16-optionals.md): Avoid NullPointerException with Java's Optional - creation, unwrapping, chaining, and best practices for handling missing values.
- [Testing](https://nhanbe.id.vn/java/beginners-guide/17-testing.md): Write your first Java tests - JUnit 5 setup, assertions, test structure, parameterized tests, and testing the Task Manager and REST API.
- [Collections and Concurrent Data Structures](https://nhanbe.id.vn/java/collections.md): Java Collections guide: List, Set, Map deep dive, immutable collections, concurrent data structures, and choosing the right collection.
- [Concurrency: Threads, Executors, and Virtual Threads](https://nhanbe.id.vn/java/concurrency.md): Java concurrency guide: threads, ExecutorService, CompletableFuture, virtual threads, thread safety, and common pitfalls.
- [Dependency Injection Without a Framework](https://nhanbe.id.vn/java/dependency-injection.md): Dependency injection in Java: constructor injection by hand, why DI matters, the Service Locator anti-pattern, and a brief intro to Spring, Guice, and OSGi.
- [Error Handling: Exceptions, Try-with-Resources, and Result Patterns](https://nhanbe.id.vn/java/error-handling.md): Java error handling guide: checked vs unchecked exceptions, try-with-resources, custom exceptions, Result/Either pattern, and logging exceptions.
- [Functional Interfaces and Lambdas](https://nhanbe.id.vn/java/functional-interfaces.md): Java functional interfaces guide: Function, Predicate, Consumer, Supplier, method references, composition, and writing custom functional interfaces.
- [Generics and Type Erasure](https://nhanbe.id.vn/java/generics.md): Java Generics guide: generic classes, methods, bounded types, wildcards, PECS principle, type erasure, and common patterns.
- [HTTP Clients: java.net.http, OkHttp, and Apache HttpClient](https://nhanbe.id.vn/java/http-clients.md): Java HTTP client guide: java.net.http HttpClient (sync and async), timeouts, retries, JSON handling, and comparison with OkHttp and Apache HttpClient.
- [Java Notes](https://nhanbe.id.vn/java/index.md): Practical Java notes covering fundamentals, modern features, backend patterns, testing, and everyday developer tools.
- [Streams and Collectors](https://nhanbe.id.vn/java/java-streams.md): Java Streams API guide: filter, map, flatMap, reduce, collect, groupingBy, parallel streams, and common pitfalls with practical examples.
- [JSON Processing: Jackson and Gson](https://nhanbe.id.vn/java/json-processing.md): Java JSON processing guide: Jackson ObjectMapper, annotations, custom serializers, polymorphism, Gson comparison, and common pitfalls.
- [Logging: SLF4J, Logback, and Log4j2](https://nhanbe.id.vn/java/logging.md): Java logging guide: SLF4J facade, Logback and Log4j2 configuration, MDC, structured logging, performance tips, and common pitfalls.
- [Maven: Project Structure, Dependencies, and Profiles](https://nhanbe.id.vn/java/maven.md): Maven guide: POM structure, dependency management, BOM imports, multi-module projects, profiles, useful plugins, and comparison with Gradle.
- [Records, Sealed Classes, and Modern Java](https://nhanbe.id.vn/java/modern-java-features.md): Guide to modern Java features: records, sealed classes, pattern matching, text blocks, var, and a version-by-version feature table from Java 11 to 21.
- [Optionals: Avoiding NullPointerException](https://nhanbe.id.vn/java/optionals.md): Java Optional guide: creation, chaining, best practices, anti-patterns, and when to use Optional vs null.
- [Testing: JUnit 5, Mockito, and AssertJ](https://nhanbe.id.vn/java/testing.md): Java testing guide: JUnit 5, Mockito mocking, AssertJ fluent assertions, parameterised tests, test patterns, and what to mock vs what not to mock.
- [Async/Await in JavaScript: Practical Patterns and Pitfalls](https://nhanbe.id.vn/javascript/async-await-guide.md): Learn async/await with TypeScript examples. Understand sequential vs parallel work, error handling, timeouts, and best practices.
- [Introduction & Environment Setup](https://nhanbe.id.vn/javascript/beginners-guide/01-introduction.md): What JavaScript is, where it runs, how to set up your development environment, and writing your first program.
- [Variables, Types & Operators](https://nhanbe.id.vn/javascript/beginners-guide/02-variables-and-types.md): Learn about JavaScript variables (let, const, var), primitive data types, type coercion, operators, and template literals.
- [Control Flow](https://nhanbe.id.vn/javascript/beginners-guide/03-control-flow.md): Learn how to make decisions and repeat actions in JavaScript with if/else, switch, ternary operators, and loops.
- [Functions](https://nhanbe.id.vn/javascript/beginners-guide/04-functions.md): Learn JavaScript functions - declarations, expressions, arrow functions, parameters, scope, closures, and callbacks.
- [Arrays](https://nhanbe.id.vn/javascript/beginners-guide/05-arrays.md): Learn JavaScript arrays - creating, accessing, mutating, iterating with map/filter/reduce, destructuring, and the spread operator.
- [Objects](https://nhanbe.id.vn/javascript/beginners-guide/06-objects.md): Learn JavaScript objects - literals, properties, methods, this, destructuring, spread, Object methods, and JSON.
- [HTML & CSS Essentials](https://nhanbe.id.vn/javascript/beginners-guide/07-html-css-essentials.md): Learn enough HTML and CSS to build web pages - document structure, semantic elements, forms, CSS selectors, the box model, flexbox, and responsive design.
- [The DOM](https://nhanbe.id.vn/javascript/beginners-guide/08-the-dom.md): Learn how JavaScript interacts with web pages through the DOM - selecting elements, modifying content, creating and removing elements, and traversing the tree.
- [Events & Interactivity](https://nhanbe.id.vn/javascript/beginners-guide/09-events.md): Learn how to handle user interactions in JavaScript - event listeners, the event object, bubbling, delegation, forms, and keyboard/mouse events.
- [Working with Data](https://nhanbe.id.vn/javascript/beginners-guide/10-working-with-data.md): Learn how to fetch data from APIs, handle JSON responses, use async/await, and store data with localStorage and sessionStorage.
- [Project: Build a Complete Website](https://nhanbe.id.vn/javascript/beginners-guide/11-project-build-a-website.md): Build a multi-page vanilla JavaScript website from scratch - navigation, theme toggle, form validation, dynamic content, and local storage.
- [Deploying to a VPS with Nginx](https://nhanbe.id.vn/javascript/beginners-guide/12-deploy-vps-nginx.md): Deploy your website to a Virtual Private Server - server setup, SSH, nginx configuration, HTTPS with Let's Encrypt, and basic security hardening.
- [TypeScript](https://nhanbe.id.vn/javascript/beginners-guide/13-typescript.md): TypeScript adds static types to JavaScript - learn type annotations, interfaces, generics, union types, and how to set up a TypeScript project.
- [Error Handling](https://nhanbe.id.vn/javascript/beginners-guide/14-error-handling.md): Handle errors gracefully in JavaScript - try/catch/finally, error types, custom errors, async error handling, and common patterns.
- [Regular Expressions](https://nhanbe.id.vn/javascript/beginners-guide/15-regular-expressions.md): Master JavaScript regular expressions - patterns, character classes, quantifiers, groups, lookaheads, and practical validation examples.
- [JavaScript Notes](https://nhanbe.id.vn/javascript/index.md): Practical JavaScript notes covering fundamentals, async programming, performance, web APIs, and security best practices.
- [JavaScript Error Handling: Patterns, Types, and Best Practices](https://nhanbe.id.vn/javascript/javascript-error-handling.md): Learn practical JavaScript error handling with TypeScript examples. Cover try/catch, async errors, custom error types, and safe logging.
- [JavaScript Intl API: Currency, Date, and Number Formatting (TypeScript)](https://nhanbe.id.vn/javascript/javascript-intl-api-formatting.md): Learn currency formatting, date formatting, number formatting, list formatting, and more with the JavaScript Intl API. Practical TypeScript examples and best practices.
- [JavaScript Performance Basics: Measure, Optimize, and Scale](https://nhanbe.id.vn/javascript/javascript-performance-basics.md): Practical JavaScript performance tips with TypeScript examples. Learn measurement, algorithmic complexity, caching, and avoiding common bottlenecks.
- [JSON Parsing in JavaScript: Safe Patterns and Practical Tips](https://nhanbe.id.vn/javascript/json-parsing-guide.md): Learn safe JSON parsing and serialization in JavaScript with TypeScript examples. Cover JSON.parse, JSON.stringify, revivers, validation, and common pitfalls.
- [LocalStorage and SessionStorage in JavaScript: Save, Load, and Remove Data](https://nhanbe.id.vn/javascript/local-session-storage.md): Learn how to store, load, update, and remove data using localStorage and sessionStorage. Includes JSON parse/stringify patterns and safe helpers.
- [User Input Sanitization in JavaScript: Practical and Safe Patterns](https://nhanbe.id.vn/javascript/user-input-sanitization.md): Learn how to sanitize and validate user input in JavaScript with TypeScript examples. Covers frontend and backend basics, XSS prevention, and safe outputs.
- [Introduction to Linux](https://nhanbe.id.vn/linux/beginners-guide/01-introduction.md): What Linux is, an overview of common distributions, why developers use it, and how to connect to a remote server via SSH.
- [Filesystem Navigation](https://nhanbe.id.vn/linux/beginners-guide/02-filesystem-navigation.md): Navigate the Linux filesystem with pwd, ls, cd, and tree, and understand the standard directory hierarchy.
- [File Management](https://nhanbe.id.vn/linux/beginners-guide/03-file-management.md): Create, copy, move, delete, and find files and directories with touch, mkdir, cp, mv, rm, ln, and find.
- [Text Processing](https://nhanbe.id.vn/linux/beginners-guide/04-text-processing.md): Read, search, and transform text files using cat, grep, sed, awk, and shell pipes and redirection.
- [Permissions and Ownership](https://nhanbe.id.vn/linux/beginners-guide/05-permissions-and-ownership.md): Understand Linux file permissions, ownership, chmod, chown, umask, and sudo for secure server access control.
- [Processes and Jobs](https://nhanbe.id.vn/linux/beginners-guide/06-processes-and-jobs.md): Monitor, control, and manage Linux processes and system services using ps, top, kill, systemctl, and journalctl.
- [Shell Scripting Basics](https://nhanbe.id.vn/linux/beginners-guide/07-shell-scripting-basics.md): Write bash scripts with variables, conditionals, loops, and command substitution to automate repetitive server tasks.
- [Functions and Script Patterns](https://nhanbe.id.vn/linux/beginners-guide/08-functions-and-script-patterns.md): Write reusable bash functions with local variables, arguments, error handling with set -e and trap, and heredocs.
- [Networking](https://nhanbe.id.vn/linux/beginners-guide/09-networking.md): Diagnose and work with Linux networking using ip, curl, wget, ss, dig, SSH config, scp, and rsync.
- [Package Management](https://nhanbe.id.vn/linux/beginners-guide/10-package-management.md): Install, update, and remove software packages on Debian/Ubuntu with apt, RHEL/Fedora with dnf, and Alpine with apk.
- [System Administration](https://nhanbe.id.vn/linux/beginners-guide/11-system-administration.md): Administer a Linux server - disk usage, cron jobs, log management, and environment variable configuration.
- [Practice Project - Deploy a Node.js App](https://nhanbe.id.vn/linux/beginners-guide/12-practice-project.md): End-to-end exercise provisioning a fresh Ubuntu VPS, securing it, deploying a Node.js app as a systemd service, and configuring log rotation.
- [Linux Notes](https://nhanbe.id.vn/linux/index.md): Practical notes on Linux commands, filesystem navigation, shell scripting, networking, and system administration.
- [Ubuntu, Debian command](https://nhanbe.id.vn/linux/note/ubuntu-command.md)
- [Note 1 - Spring Boot Fundamentals](https://nhanbe.id.vn/springboot/note1-springboot-fundamentals.md)
- [Introduction to Software Testing](https://nhanbe.id.vn/testing/beginner-guide/01-introduction.md): Why testing matters, the testing pyramid, cost of bugs, coverage as a metric, and a tooling overview for JavaScript/TypeScript and Java projects.
- [Unit Testing in JavaScript & TypeScript](https://nhanbe.id.vn/testing/beginner-guide/02-unit-testing-javascript.md): Setting up Jest and Vitest, writing describe/it/test blocks, using expect matchers, lifecycle hooks, and running your test suite.
- [Unit Testing in Java with JUnit 5](https://nhanbe.id.vn/testing/beginner-guide/03-unit-testing-java.md): JUnit 5 setup with Maven and Gradle, @Test, lifecycle annotations, Assertions, @DisplayName, @Nested, and parameterised tests.
- [Mocking in JavaScript & TypeScript](https://nhanbe.id.vn/testing/beginner-guide/04-mocking-javascript.md): jest.fn(), jest.spyOn(), jest.mock() for modules, clearing and resetting mocks, mocking fetch and axios, and testing async code.
- [Mocking in Java with Mockito](https://nhanbe.id.vn/testing/beginner-guide/05-mocking-java.md): Mockito setup, @Mock and @InjectMocks, when().thenReturn(), verify(), ArgumentCaptor, mocking exceptions, and spy objects.
- [Integration Testing](https://nhanbe.id.vn/testing/beginner-guide/06-integration-testing.md): What makes a test an integration test, testing database interactions, testing HTTP endpoints with Supertest and MockMvc, and Docker-based testing with Testcontainers.
- [Test-Driven Development (TDD)](https://nhanbe.id.vn/testing/beginner-guide/07-tdd.md): The red-green-refactor cycle, when TDD makes sense, a worked example building a shopping cart in both TypeScript and Java, and common TDD pitfalls.
- [React Component Testing](https://nhanbe.id.vn/testing/beginner-guide/08-react-component-testing.md): React Testing Library setup, render/screen/fireEvent/userEvent, querying by role and text, testing forms, and testing components that fetch async data.
- [Snapshot & Visual Testing](https://nhanbe.id.vn/testing/beginner-guide/09-snapshot-and-visual-testing.md): Jest snapshot testing pros and cons, updating snapshots, when to use them, and an introduction to Storybook for visual component testing.
- [End-to-End Testing with Playwright](https://nhanbe.id.vn/testing/beginner-guide/10-e2e-testing.md): Playwright setup, writing your first test, page navigation, clicks, form fills, selectors, headless execution, traces and screenshots on failure, and CI integration.
- [Test Coverage](https://nhanbe.id.vn/testing/beginner-guide/11-test-coverage.md): Coverage metrics (line, branch, function), configuring Istanbul and JaCoCo, setting thresholds, what good coverage means, and collecting coverage in CI.
- [Practice Project: TypeScript Utility Library](https://nhanbe.id.vn/testing/beginner-guide/12-practice-project.md): End-to-end exercise - build and test a small TypeScript utility library with Vitest (unit and integration tests), full coverage report, and GitHub Actions CI.
- [Testing Notes](https://nhanbe.id.vn/testing/index.md): Practical notes on software testing, unit testing, integration testing, mocking, and TDD across JavaScript and Java.