I’ve written about use cases for and benefits of Sling resource decoration. I thought it’d be good to follow up with some more notes I had on resource decoration.
Registered resource decorators respond every time Sling resolves a resource, so it’s important that resource decorators quickly bow out when they are not needed. Return as early as possible from the
decorate method to prevent unnecessary code execution for every resource resolution.
Keep it Simple
Similarly, since registered resource decorators respond to every resource resolution, you want to keep the
decorate method as simple as possible.
I’ve seen examples of resource decorators that contain basic control flow and string comparisons on paths and resource types; these are good examples of acceptable and safe operations during resource decoration. I personally strive to keep resource decorator code small and similarly simple.
If you do need to perform more complex operations, you can still limit your resource decorator code to wrapping your target resource with a
ResourceWrapper, and create methods on that implementation that perform your more complex logic. This way, you can keep your resource decorator code simple, and defer your complex logic to a later method call, when the system needs that logic to be performed.