products;
```
> \[!-success] -success
> tip
>
> Prefer setting `defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL` on the `@Model` annotation and only override with `REQUIRED` on fields that truly must exist. This prevents the entire model from returning `null` when a single optional field is missing.
## Rendering in HTL
Once the Sling Model is set up, iterate over the child resources in your HTL template:
```html
-
${product.productId}
${product.originalPrice}
${product.originalPrice}
Add products to display the list.
```
## Manual Loop Alternative
Sometimes `@ChildResource` is not flexible enough. You may need manual iteration when:
- You need to **filter** or **sort** entries based on custom logic
- You need access to the `SlingHttpServletRequest` in the child processing
- The child nodes don't have a uniform structure
- You need to apply **transformations** that require services or the request context
```java
@Model(adaptables = SlingHttpServletRequest.class,
defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)
public class FilteredProductList {
@SlingObject
private Resource resource;
@SlingObject
private SlingHttpServletRequest request;
private List activeProducts;
@PostConstruct
protected void init() {
activeProducts = new ArrayList<>();
Resource productsNode = resource.getChild("products");
if (productsNode != null) {
for (Resource child : productsNode.getChildren()) {
// Adapt the child node to the Product model
Product product = child.adaptTo(Product.class);
if (product != null && StringUtils.isNotBlank(product.getProductId())) {
activeProducts.add(product);
}
}
}
}
public List getActiveProducts() {
return Collections.unmodifiableList(activeProducts);
}
}
```
| Approach | Pros | Cons |
| ---------------- | ----------------------------------------------- | -------------------------------------------- |
| `@ChildResource` | Minimal code, declarative, automatic adaptation | No filtering, no request context in children |
| Manual loop | Full control, filtering, request-aware | More boilerplate, must handle null checks |
## Common Patterns
### Nested child resources
Child models can themselves contain `@ChildResource` fields for deeply nested structures:
```java
@Model(adaptables = Resource.class,
defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)
public class Section {
@ValueMapValue
private String sectionTitle;
// Each section has its own list of items
@ChildResource
private List items;
}
```
### Multifield inside a tab or accordion
When a multifield lives inside a dialog tab, the JCR structure stays the same - the multifield's `name` attribute determines where the child nodes are stored, regardless of the dialog layout structure:
```xml
```
### Using @Via for child resources on a different path
If the child data lives under a different resource than the component node (e.g. the `jcr:content` child of a referenced page), combine `@ChildResource` with a `@Via` annotation or resolve manually:
```java
// Read child resources from a specific sub-path
@ChildResource(name = "jcr:content/items")
private List pageItems;
```
## Best Practices and Common Pitfalls
### Always use composite=true
Without `composite="{Boolean}true"`, the multifield stores values as multi-value properties. This breaks `@ChildResource` injection and limits you to a single field per entry.
### Child model must adapt from Resource
The child model class **must** declare `adaptables = Resource.class`. The `@ChildResource` injector passes a `Resource` to `adaptTo()`, not a `SlingHttpServletRequest`.
```java
// Correct - child model adapts from Resource
@Model(adaptables = Resource.class)
public class Product { ... }
// Wrong - @ChildResource cannot adapt a request
@Model(adaptables = SlingHttpServletRequest.class)
public class Product { ... }
```
### Handle missing child nodes
If the author hasn't added any multifield entries yet, the child node won't exist. Always null-check:
```java
public List getProducts() {
return products != null ? Collections.unmodifiableList(products) : Collections.emptyList();
}
```
### Avoid deep nesting
Deeply nested multifields (multifield within a multifield) create complex JCR structures that are hard to query and maintain. Prefer flat structures where possible, or consider Content Fragments for highly structured data.
### Performance with large lists
`@ChildResource` loads all child nodes eagerly. For components with a very large number of entries (50+), consider lazy loading or pagination. In practice, most multifield components have fewer than 20 entries, so this is rarely an issue.