dantaframework / aem Goto Github PK

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:

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

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

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

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.

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.

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