Introduced by Adobe Consulting is an extremely useful set of tools for AEM. If you haven't installed them already, I'd highly recommend it:

ACS Tools

Of particular note herein is the AEM Fiddle tool. Whereas we have wonderful free tools on the web such as JSFiddle or Codepen wherein we can mock things up and sketch out some code before dropping it in our repo, there really wasn't a good solution for AEM-specific "fiddling" until now. The AEM Fiddle tool does exactly what you'd expect:

  1. Enter some JSP code
  2. Run said JSP code
  3. See result in real time

That alone makes the tool worth having but why stop there? Adobe has also baked in the following features:

  • Can run JSPs, Sightly templates, ECMAScript, Handlebars templates, Javascript Templates and can even compile and run Java servlets for you!
  • Saves out fiddles for later reuse
  • Tracks stats on the fiddles you create (for what purpose I'm unsure but it's there)

What's particularly interesting about this for me, is that the engagement I'm currently on involves a LOT of content. Further, the majority of this content must be migrated from a legacy system to the new hotness where the code works differently. As a result, we've done our fair share of content mangling and massaging. We've written helper servlets and fiddles alike until our fingers grew tired and the darkness of slumber took us like the river's current on a fall day... Okay, that's an exaggeration but you get the idea. You can only write so many fiddles and servlets before the following question needs answering: Which is the better approach "helper" scripts/services within your AEM projects: fiddling or servlet-ing? To be clear, when I say "servlet-ing", I'm referring specifically to path-based servlets you'd install as a Sling service. There are clear advantages to both:

  • Fiddling
    1. Generally quicker to write and use
    2. Doesn't require a build and can be run as-is on any environment with ACS Tools installed
    3. Errors and bugs can be resolved on the spot and the code re-run in real time
    4. Instant gratification
  • Servlet-ing
    1. Under source control
    2. Much easier reuse
    3. Extensible

To evaluate, let's briefly take a look at what each approach might look like:

A Path-based Servlet


package com.yolo.swag.cq;

import org.apache.felix.scr.annotations.sling.SlingServlet;
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.SlingSafeMethodsServlet;
import org.slf4j.Logger;

@SlingServlet(paths = "/bin/mywickedservlet", name = "com.yolo.swag.cq.MyWickedServlet")
public class MyWickedServlet extends SlingSafeMethodsServlet {

    private static final long serialVersionUID = 1L;
    private static final Logger log = org.slf4j.LoggerFactory.getLogger(MyWickedServlet.class);

    @Override
    protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) {
        // Do something wicked

        // Return the result of your wickedness
    }
}

A JSP Fiddle


<%@include file="/libs/foundation/global.jsp"%>
<%@ page
    session="false"
    contentType="text/html; charset=utf-8"
    pageEncoding="UTF-8"
    import="org.slf4j.Logger"%>
<%
    // Do something wicked
%>

Display the result of your wickedness

So which of the above is the better approach? For me, it really depends upon your use case and the answer to some of the following questions:

  1. Is this service a one-time deal or will it see use again in the future?
  2. Are you the only one who is ever going to use this or will others need it too?
  3. How strict is the team lead overseeing the repository? Will they scoff at the idea of a Sling service for seemingly one-off use cases?

Obviously the above questions have some grey area. Your use case may not be a one-time deal but it may also see limited use. Right now you may be the only one that needs this but it may benefit others in the near future. Your tech/team lead may be a repository "purist" or "repurist" (I take full responsibility for claiming this term) but there may not be a truly viable alternative.

As a lovable young actress in a famous commercial once said:


Why not both?

The approach I've arrived upon and recommend brings both sides to the table. I fiddle until I'm satisfied and then convert to a path-based servlet to ensure it's covered in source control and is easily reusable without passing scripts around via email. I get enough chain emails anyway.

What's your approach? Let me know via comments!