Passing request attributes with Sightly

_nodes.txt

/content
    /example
        @jcr:primaryType = "nt:unstructured"
        @jcr:title = "Outer Component"
        @sling:resourceType = "example/components/outer"
        /one
            @jcr:primaryType = "nt:unstructured"
            @jcr:title = "Inner Component One"
            @sling:resourceType = "example/components/inner"
        /two
            @jcr:primaryType = "nt:unstructured"
            @jcr:title = "Inner Component Two"
            @sling:resourceType = "example/components/inner"
/apps
    /example
        /components
            /inner
                @jcr:primaryType = "cq:Component"
                /inner.html
                /inner.js
            /outer
                @jcr:primaryType = "cq:Component"
                /outer.html
                /outer.js

_output.html

<div class="outer">
    <h1>Outer Component</h1>
    <ul>
        <li>
            <div class="inner">
                <h2>Inner Component One</h2>
                <p>Hello World!</p>
            </div>
        </li>
        <li>
            <div class="inner">
                <h2>Inner Component Two</h2>
            </div>
        </li>
    </ul>
</div>

inner.html

<div class="inner" data-sly-use.logic="inner.js">
    <h2>${properties.jcr:title}</h2>
    <p data-sly-test="${logic.attributes.foo}">
        ${logic.attributes.foo}
    </p>
</div>

inner.js

use(function () {
    return {
        attributes: request.getAttribute(resource.getPath())
    };
});

outer.html

<div class="outer" data-sly-use.logic="outer.js">
    <h1>${properties.jcr:title}</h1>
    <ul data-sly-list="${resource.listChildren}">
        <li data-sly-resource="${item.name}"></li>
    </ul>
</div>

outer.js

use(function () {
    request.setAttribute(resource.getPath() + "/one", {
        foo: "Hello World!"
    });
});

quite simplistic.. :)

This example boils it down to the minimum, in order to expose the concept. But that idea can be tweaked and extended to whatever is needed. The core concept put forward here is to name the request attributes in such a way to specifically address the resource(s) for which the passed data is intended. That way, the request attributes can be set anywhere, and they don't have to be removed after the concerned resource has been included.

Another idea of what could be done is to use resource types for request attribute names, in order to target the data for a whole category of components. Or to come up with a custom naming that corresponds to more special needs.