What is Sling Model Exporters?

Sling Models

Sling Models are business objects that represents sling resources or sling requset objects in AEM. In other way, Sling Models let you map Java objects to Sling resources.

Sling Models Exporter

Sling Model Exporters helps to export the model as a different Java object (serialized into a different format such as JSON) by adding annotations to Sling Model. The model is programmatically exported by calling the ModelFactory method exportModel().

Jackson exporter
 
Jackson exporter which is used in Sling allows to convert Sling Model into a Java Map object. Jackson JSON exporter helps exporting Sling Models as JSON objects, which can be accessible from other third party web service applications, Java script application etc.

Sling Model Exporter is available from Sling Models version v1.3.0. 

Pictorial representation of Sling Model Vs Sling Model Exporter

Click on image to see it big

Can I use Sling Model Exporters with versions prior to AEM 6.3?

Yes AEM 6.3 onward no extra dependencies required to use Sling Model Exporters.

But versions prior to AEM 6.3 requires installation of below bundled packages from,
Sling > Downloads

• Models API 1.3.0+
• Models Implementation 1.3.0+
• Models Jackson Exporter 1.0.0
• AEM 6.2 Communities/Livefyre - FP2

How to add exporter framework to an existing sling model?

1) Add a resource type to a model,

Add below line in @Model code block of Sling Model.

resourceType = "[The type of the resourcse which we are requesting]";

2) Add a new annotation,

@Exporter ( name = "jackson", extensions = "json")

Associate a model class with a resource in SlingDocumentation here

After building the code, invoke the resource with selector model.json

This will bring back the response in JSON format and the response is picked from the getter methods in the sling model class.

Sling Exporter Documentation

Demo Video

 

Read More:

Sling Model Vs WCMUsePOJO

Sling Models vs WCMUSEPOJO

AEM component back-end logic was shifted over years from JSP’s to WCMUse class to WCMUsePOJOs and then to Sling Models.

AEM 6.1 or 6.2 were supporting WCMUsePojo class; AEM 6.2 and 6.3 started to support the Sling Models approach.

Both WCMUsePOJOs and Sling Models are used with HTL using <data-sly-use> block.

Before we jump into the difference , let us understand the concepts.

What is a POJO(Plain Old Java Objects)?

POJO's are simple Java classes which doesnt depend on other libraries, interfaces or annotations. This increases the chance that this can be reused in multiple project types. POJO's provides Getter and Setter methods, which allow you to change the underlying data type without breaking the public interface of your class which makes it more robust and resilient to changes.

What if there are no getters and setters?

Say we havent created setter and getter methods, then any one can directly call the variable and it surely will affect to the code, which may lead to security issues. Here POJO class are forcing other coder to call on the methods rather than directly calling the Instance variables.

What is Sling Models?

Sling Models are annotation driven POJOs. They allows to map resource properties, assign default values, inject OSGI services and much more.

Sling Models are pure POJOs that gives wonderful separation between logic and presentation which also extensible with custom injectors and annotations. Sling Models let you map Java objects to Sling resources. 

Use API Vs Sling Model

Use API

HTL(Formerly known as Sightly) uses  two ways of implementing support for business logic objects:
1) Java Use-API, through POJOs,
2) JavaScript Use-API,

Regular POJOs that extend WCMUsePojo implement the Use interface and are initialized with the scripting bindings, providing convenience methods for accessing commonly used objects like request, resource, properties, page etc.

HTL implementation from Sling provides the basic POJO support through the org.apache.sling.scripting.sightly.pojo.Use interface and the JavaUseProvider, whereas the use function is implemented by the org.apache.sling.scripting.sightly.js.provider bundle.

The Sling implementation provides a few extensions to the Use-API.

Sling Model API:

Sling Models are more flexible which can also be used outside HTL, thus makes the business-logic more reusable. They are managed by Sling and can be injected references to other objects using annotations and reflection.

Click on image to see it big

Conversion from WCMUsePojo to SlingModel
Just by adapting the above said methods (Remove 'Extends WCMUse', Add sling model annotation on top of the class, then add inject methods to invoke the references.) a developer can easily convert WCMUsePojo to SlingModel.

Conclusion:

For the versions AEM 6.3, AEM 6.4 and AEM Core WCM Components, Adobe recommends using Sling Models as the best practice.
 
More Details Here

Picking-the-best-use-provider-for-a-project

Video of the comparison 
 

Read More:

Sling Model Vs Sling Model Exporter

Performance Monitoring in AEM Projects

There are many reasons for performance issue in AEM projects. Identifying them and fixing in right time is mandatory to make the project successful.

Common causes of performance issues

From years people were monitoring performance issues  and identified a pattern. The issues starts from beginning of the project to end. Examples could be a poor design, poorly written code, lack of caching, memory sizing, network bandwidth latency, no proper load balancing at end point etc.

How to prevent performance issues?

1) By running multiple tests: Load tests, stress tests etc can help identifying the issues before launch.
2) Stable AEM release: Install any recommended service packs, cumulative fixes, hot fixes etc.
3) Following guidelines : Follow Assets best practices recommended by Adobe, Content Architecture guidelines etc.
4) Proper Memory Management: Allocate sufficient RAM , disk space based on research guidelines.
5) Configurational practices: Proper logging,  Caching, Sling job queue tuning etc
6) Workflows tuning: Enable transient workflows, purge workflows on time etc.
7) Oak tuning : by creating custom indexing for repeated searches, Ensuring proper JVM parameters for index querying, better lucene index configuration, external data store for huge assets handling.
8) Tar storage tuning: TarMK revision clean, OS related fixes for Tar etc.

Adobe Cloud manager is having ability to identify many of such issues.

Always keep monitoring the system and check for the bug reports , Adobe forums etc to identify

Read More>> Performance in Cloud Manager

How can we create a custom datatype in the content fragment models in AEM

For majority of the use cases, the given content fragment datatypes will satisfy any use cases. But still if we need to extend the data type functionality further, below approach can be tried.

To start with, let us understand the data type structure in AEM.

Content Fragment model data types are configured at:
/libs/settings/dam/cfm/models/formbuilderconfig/datatypes/items/enumeration

and each dataype has properties as below,

• fieldIcon
• fiedPropResourceType
• fieldProperties
• fieldResourceType
• fieldTitle
• fieldViewResourceType
• renderType
• valueType

There are some additional fields which are specific to the fields.

Now, if you observe closely,

• fiedPropResourceType having string value 'dam/cfm/models/editor/components/datatypes/field'
• fieldIcon, fiedTitle -are data type naming specific.
• fieldResourceType, renderType, valueType - are behavior specific to the data types.

All the fieldResourceType values are referred from /libs/granite/ui/components/coral/foundation, /libs/dam/cfm/models/editor/components, /libs/dam/cfm/admin/components etc.

Below given a screenshot of default Boolean data type properties.

 

Custom?

Now say if you need to create a custom data type for the content fragment, you can create a project specific structure of the data type referring the default one, the same way we extend the components.

If there is any other way to implement this, please let me know through the comments.

List of leading Headless CMS Solutions

What is Headless CMS?    
 
 HEADLESS = content.

What makes a real headless CMS? A headless cms is having a content first approach WITH full APIs to access the content in any way you want. Content first must be the approach behind Content Architecture. You start with looking at your content and structuring it and how it can be used now and in the future before you think of building anything UI wise. Its simple, Content First approach.

Below given a narrow list of headless CMSs in addition to AEM.

•     Agility CMS
•     Butter CMS
•     Acquia
•     e-Spirit
•     Contentstack
•     Contentful
•     dotCMS
•     Mura
•     Cloud CMS
•     Cockpit CMS
•     Core dna
•     Craft CMS
•     Zesty.io
•     Directus
•     Storyblok
•     GraphQL CMS
•     Gentics Mesh
•     Cosmic JS
•     Kentico Cloud
•     Prismic.io
•     Quintype
•     Sanity
•     Scrivito
•     Squidex
•     DNN Evoq Content
•     Strapi
•     Superdesk