dantaframework / aem

This package contained Danta Framwork's specific set of codes for AEM (Adobe Experience Manager).

Danta - AEM Project

Danta is the agnostic multi-platform templating engine. enables developers and IT teams to use technologies they already know, expediting the creation and leveraging of reusable technical assets.

Danta - AEM Project is the maven project contained source codes specifically for AEM.

Prerequisites

• ACS AEM Commons 3.9.0 or later
• Danta - Parent Project
• Danta - API Project
• Danta - Core Project
• Java 8
• AEM 6.2 or later (for integration with AEM)

Documentation

Installation

• Via AEM Package Manager, install ACS AEM Commons 3.9.0 or later

• Clone the following repositories into the same folder (i.e. C:\workspace\danta or /User/{username}/workspace/danta) then run the maven build command (refer to Compile section of README.md, for each repository) in the following order

  • AEM Base
  • Parent
  • API
  • Core
  • AEM

  Note: for fresh installation, make sure to install ACS Common before running the maven build command

Official documentation

• Read our official documentation for more information.

License

Read License for more licensing information.

Contribute

Read here for more information.

Compile

mvn clean install

Deploy to AEM

Build to author instance

mvn clean install -Pdeploy-aem

Build to publish instance

mvn clean install -Pdeploy-aem -Daem.server=http://localhost:4503

Credit

Special thanks to Jose Alvarez, who named Danta for the powerful ancient Mayan pyramid, La Danta. La Danta is the largest pyramid in El Mirador—the biggest Mayan city found in Petén, Guatemala.

aem's Issues

SlingModels cannot be used outside AEM Bundle

Current behavior

When I create a SlingModel Class and configure it to use AddSlingModelsPropertiesContextProcessor it complains that the SlingModel Class is not found because the AEM bundle is not importing the class in OSGi

Expected behavior

It should add the SlingModel Data into the ContentModel

Possible solution

Add DynamicImport in the OSGi Manifest for AEM Bundle

Steps to reproduce (for bugs)

1. Configure a SlingModel in any bundle outside the AEM Bundle it will not work and will throw error

Environment (for bugs)

• Danta versions: 1.0.0
• AEM version: 6.3
• Java version: 1.8

Not getting tags information in Page Context of the contentModel

Current behavior

Trying to get the tags information by using page.[cq:tags] is not working. If you inspect the content of the Page Context you'll notice there is a "page.tags" property but it is empty even when the jcr:content node of the page actually has an array of strings in the "cq:tags" property.

Expected behavior

page.tags should provide an array of strings in which each element should correspond to a tag.

Possible solution

The AddPagePropertiesContextProcessor is obtaining a map of page properties by calling a propsToMap() method which is internally filtering the reserved system name prefixes. This is making "cq:tags" property not being included because it starts with "cq:".

A possible solution could be reading tags either from the page object (Page page = pageManager.getContainingPage), the Resource object (page.getContentResource) or the Node object (Node pageContentNode = page.getContentResource().adaptTo) and then adding the tags array to the "tags" property in the "pageContent" map.

Steps to reproduce (for bugs)

1. In an AEM running instance, go to author mode and add tags to a given page using the page properties configuration dialog.
2. In the template or any component of the page, print the Page Context using: {%page%}
3. Search for the "tags". You'll notice tags property is empty.

Environment (for bugs)

• Danta versions: 1.0.6
• AEM version: 6.4
• Java version: 1.8.0_144

Handlerbars clientlibrary directive ignore value of minify flag

This directive:

{% clientLibrary "mycompany" type="js" minify="false" %}

Is going to use the minified version of the client library regardless the value set to false.

Export danta.aem.util package

Consider to export the package aem.util it's mostly used for internal stuff, but contains util functions (e.g. PropertyUtils.propsToMap(componentNode))

Current behavior

The package danta.aem.util is not exported

Expected behavior

There are util functions that should be exported

Possible solution

Exported the package inside the pom.xml in section <Export-Package></Export-Package>

Steps to reproduce (for bugs)

(It is not a bug)

Environment (for bugs)

• Danta versions:
• AEM version:
• Java version:

Using resource properties that contain with ":" within their name

I am not able to perform things such as:

{%content.jcr:title%}

Using ":" is a very typical practice in JCR based apps, such as AEM, as this is how you define namespaces for your properties. As a practical example, suppose that I need to have custom metadata properties for an AEM Asset and I want remove any possibility of a collision with metadata property names from others.

Also all of the AEM out of the box components that deal with titles for example, use jcr:title as the property name

This seems to work alright for properties with ":" that are part of a cq:Page's jcr:content node, but not for other resources

Please add support for this.

Thanks

Null Pointer exception when trying to read Design context.

Current behavior

Currently a null pointer exception is thrown when "AddDesignPropertiesContextProcessor" tries to access the designer style.

Expected behavior

There should not be any null pointer exception when trying to read from Design context.

Possible solution

To add the null validation. This is the current validation (lines 80 to 84):

if (style.getPath() != null) {
                Resource designResource = resourceResolver.getResource(style.getPath());
                Map<String, Object> designMap = (designResource != null) ? PropertyUtils.propsToMap(designResource) : new HashMap<String, Object>();
                contentModel.set(DESIGN_PROPERTIES_KEY, designMap);
}

This is how it could validate the null for "style":

if (style != null && style.getPath() != null) {
                Resource designResource = resourceResolver.getResource(style.getPath());
                Map<String, Object> designMap = (designResource != null) ? PropertyUtils.propsToMap(designResource) : new HashMap<String, Object>();
                contentModel.set(DESIGN_PROPERTIES_KEY, designMap);
}

Steps to reproduce (for bugs)

1. In a 6.4 AEM instance, create a new page that wouldn't have any styles saved in designs folder.
2. Create a context processor that runs when the page is loaded.
3. In the context processor, add the code to access the Design context from the content model.
4. Build changes and deploy them to a local AEM 6.4.
5. Go to the new page that was just created so that the context processor tries to access to Design context.

Environment (for bugs)

• Danta versions: 1.0.6
• AEM version: 6.4
• Java version: 1.8.0_144

Cleanup: TemplateContentModelImpl needs a lot of attention

TemplateContentModelImpl has several issues which will make it difficult for external contributors to work with it. Examples:

• General organization. There are public, private, protected, and default visibility methods scattered throughout the class. There is also an enum and a field defined in seemingly random locations between methods. Perhaps these could be reordered to promote readability and clarity.
• Methods with default visibility (package-private) are a code smell. If possible, let's get rid of these.
• Some methods are synchronized, but the class as a whole is not thread-safe. Do these methods need to be synchronized? Could a comment be added to provide some explanation?
• Some fields are volatile, but I don't think this provides the thread-safety that they were intended to. Reconsider these.
• There are unused methods such as newInstance(). There is also commented out code. Remove these.
• There are unnecessary methods which should be removed, such as response() (is only used internally by wrappedResponse(), and simply returns a field) and toJSONString() (used only by toString()). Likewise, there is a non-private inner class CharResponseWrapper which is only used once, internally. That could be inlined as an anonymous inner class.
• Generally, I don't think wrappedResponse() belongs in this class. The response wrapping should probably be moved to the calling class: IncludeResourceHelperFunction.