AbstractResourceVisitor for traversing resource trees

We often come across features that require traversal of a resource tree (e.g. processing assets in a folder). In such scenarios, recommendation is to use tree traversal than queries. More details of similar scenarios can found on link 

Sling provides AbstractResourceVisitor API, which performs traversal through a resource tree, allowing a developer to focus on processing child resources.

How to use AbstractResourceVisitor?

Step 1: Create class that extends AbstractResourceVisitor

Step 2: Implement visit() to process child resources

class ProcessChildVisitor extends AbstractResourceVisitor {
    @Override
    protected void visit(Resource resource) {
        //Business logic to process the resource
    }
}

• The visit method will be called for each child resource of ‘parentResource’ mentioned in Step 3

Step 3: Initiate processing of child resources by calling accept() of class created in Step 2

    ProcessChildVisitor processChildVisitor = new ProcessChildVisitor();
    processChildVisitor.accept(parentResource);

Code for AbstractResourceVisitor class can be found on link

Improving traversal for specific node types

There might be instances, where we need to traverse only specific type of child resources (e.g. Assets). To implement such scenarios:

Step 1: Create a class that extends AbstractResourceVisitor

Step 2: Override accept() Or traverseChildren() method.

• accept() decides if the child resources of current resource should be iterated.
• traverseChildren() iterates over child resources.

Example: Consider that we need to iterate over all Assets in a folder. As we iterate, we should NOT process:

• sub-folders, but only the assets that they contain.
• resources below asset (e.g renditions).

Below is the snippet to implement such a Resource Visitor :

import org.apache.sling.api.resource.AbstractResourceVisitor;
import org.apache.sling.api.resource.Resource;

import com.adobe.granite.asset.api.Asset;

/**
* The <code>AbstractAssetVisitor</code> helps in traversing a
* resource tree by decoupling the actual traversal code
* from application code. Concrete subclasses should implement
* the {@link AbstractAssetVisitor#visit(Resource)} method.
*
*/
public abstract class AbstractAssetVisitor extends AbstractResourceVisitor {

    /**
    * Visit the given resource and all its descendants.
    * @param res The resource
    */
    @Override
    public void accept(final Resource res) {
        if (res != null) {
            visit(res);

            if(res.adaptTo(Asset.class)==null){
                traverseChildren(res.listChildren());
            }
        }
    }
}