Are we misusing Sling?

[LinearGradient]

Hi,

As part of a CQ5 project of ours, we have implemented a custom administration dashboard using AngularJS. This app, along the rest of our project, is deployed to a CQ5 instance as an OSGi bundle.

In our app, we have implemented a few servlets to let the admin interface communicate with the backend. All data communication is through JSON.

It seems to me we are misusing Sling here, because:

• We are not using any of the functionality provided by Sling (renditions, selectors, etc.)
• Sling servlets are not appropriate as a RESTful backend for CRUD actions. For example, if we map a servlet to the /bin/.../Themes path, it is not possible to map GET /bin/.../Themes/1/edit to the same servlet out of the box if we have to. Similarly Sling servlets are not flexible enough if we want to implement custom actions (e.g. POST /bin/.../Themes/1/deactivate)

Am I correct? Doesn't it make sense to avoid using Sling for this part of the project?

Thanks.

[smacdonald2008 · Accepted solution]

With AEM -- you can use traditional JSP/Servlet web programming techniques as well. That is, a JSP can call an OSGi operation and get back data. Likewise, you can post data from a CQ page to a backend servlet using AJAX. 

Traditional JSP/Servlet web programming techniques is not Sling and you are not using Sling Extension, etc. However -- not all AEM projects have to use Sling.

Instead -- you can program AEM OSGi bundles and invoking them from front-end JSPs. For more information, see the AEM Developer White Paper: http://helpx.adobe.com/content/dam/help/attachments/white5.pdf.

See this document for a good comparison between SLing and traditional web programming that uses Servlets and JSPs:

http://sling.apache.org/site/sling-api.html

[justin_at_adobe]

Hi,

While you haven't provide a lot of details, it sounds like your API is not following REST principals.

Your admin interface should communicate with the backend in terms of resources where each resource is identified by its path. "edit" and "deactivate" are actions which you would perform *on* the resource, not part of the resource path itself (although FWIW, this model is supported by Sling using the "suffix" feature, although this case would be a misuse of suffixes). One common idiom used is to include the action as a POST parameter named :operation. This is how the default Sling POST Servlet works, but is not a requirement of Sling itself.

Regards,

Justin

[smacdonald2008]

With AEM -- you have many tools that you can use. You can write your own services/servlets with OSGi, use different JavaScript frameworks (which you did), and so on. You do not need to use Sling functionality in all cases. For example, when writing a back end service that can search and pull data from the AEM JCR, you can use:

1- JCR API -- for information -- see: http://helpx.adobe.com/experience-manager/using/querying-experience-manager-data-using1.html

2 -Query Builder -- for information -- see http://helpx.adobe.com/experience-manager/using/using-query-builder-api1.html.

3 - Sling API - for information -- see http://helpx.adobe.com/experience-manager/using/using-sling-apis.html.

Your front ends can be written in different frameworks (ie - JQuery, etc) using ClientLibs and can make back end calls, get data, encode the data as JSON, etc and pass to the front end where its displayed.  

[Paul_McMahon]

To follow up on Justin's comments if you want fully embrace Sling rather than thinking as servlets registered at a single location your Sling servlets are registered to an HTTP method, an extension, or a selector but apply all paths. Then the target of your client side applications request is the path to the node your are trying to perform a CRUD application on plus the correct combination of extension, selectors, HTTP method and node or resource type. You can see this pattern in the default Sling POST servlet but also in many of the servlet's that drive CQ's admin interface.