AEM Design patterns: Admin pages and dynamic content

A common requirement in AEM projects is for authors to centrally manage some type of data, e.g. Events, and have that information display across the entire site.

There are a few technical challenges to overcome using this pattern — almost all involving caching. Dispatcher caches entire pages as single files. To update part of the page means clearing the entire file off dispatcher — along with the assorted performance cost.

Let’s take an example problem: an up-to-date events calendar that displays on every page of the site.

There are a few ways you could handle this:
1. Have dispatcher auto invalidate all pages on the site after a certain interval. This would work and be the easiest to develop but have serious negative performance implications, especially if events were updated regularly.

2. Create a servlet to create a JSON feed that is then used to create the events calendar on the front end. In this case, you would simply need to clear the cache for the JSON feed each time events were updated. The downside is that these events will not be available for SEO, which may or may not be acceptible.

3. Use server side include technology (SSI) or Edge side includes (ESI) to allow injection of these html fragments at either the dispatcher/webserver level or at the CDN level. The upside of this approach is that pages are still cached and available for SEO and there is less front-end JS load which easier on clients and mobile devices. The downside is that SSI and ESI are somewhat harder to develop against and test.

I’ll cover both approaches in this and future posts. For most AEM clients I believe that option #2 — using AJAX, is the best overall option. It’s generally easy to develop, well understood by developers, and relatively easy to test. As an added bonus, you will have an easy to parse events feed that can be used by 3rd party partners.

Building a JSON/XML feed from administration screens.
Hopefully if you are reading this blog you are already using Sling Models. If so, great! but I have some bad news. For some reason that I haven’t had a chance to investigate the annotations for sling models and the annotations for Jackson and JAXB don’t always play nice together. It’s possible for this that you will need to create a “feed” class with identical fields that gets the Jackson/JAXB annotations and the normal “model” class that you use inside of AEM for other purposes. Just a heads up!

That being covered, the rest is pretty simple. The details will vary a bit depending on your exact business requirements. A good rule of thumb is to create your servlet under a path like the following:
/bin/feeds/events.json

And use selectors for other aspects of the query, e.g. a date range:
/bin/feeds/events.10–24–2014.11.30.2014.json

You can also use extensions for filtering while maintaining caching:
/bin/feeds/events.10–24–2014.11.30.2014.json/TopEvents

Once events for a certain range are fully authored, they aren’t likely to change. This approach and URL structure maintains the dispatcher caching of your feeds and maximizes performance.

The second half of the puzzles is how to clear the dispatcher cache when new events are authored. Your authoring won’t be taking place under /bin/feeds but more likely a path like /content/admin/events/…

The good news is that this problem is already solved for you. The ACS Commons bundle has two utilities to help with this: a dispatcher flush service that allows you to automatically flush paths if data under a different path is changed and activated. A perfect fit for our needs.

The second tool is a manual dispatcher flush ui. If for some reason you need to clear a cache manually, this makes this much easier.