[
https://issues.apache.org/jira/browse/SLING-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573816#comment-17573816
]
Michal Cukierman commented on SLING-11504:
------------------------------------------
Till now I've faced two issues:
1. WCM Components API (Both AEM and WebSight):
`sling:resourceType` has a special meaning in the ws:Component (or
cq:Component). By default, the resourceType is taken from the path, so if you
create a component instance using `/apps/wcm/core/components/text` (you drag it
in the authoring editor onto a page), the content will have sling:resourceType
set to "wcm/core/components/text". This can be overwritten by setting
sling:resourceType property on `/apps/wcm/core/components/text`. In practice
you can use it to define components variants with different initial contents
like:
* /apps/wcm/components/container/one-column (with property
sling:resourceType="wcm/components/container")
* /apps/wcm/components/container/two-column (with property
sling:resourceType="wcm/components/container")
* /apps/wcm/components/container/three-column (with property
sling:resourceType="wcm/components/container")
There may be different use cases than variants. The API is here:
[https://developer.adobe.com/experience-manager/reference-materials/6-4/javadoc/com/day/cq/wcm/api/components/Component.html#getResourceType--]
{quote}Returns the resource type to be used for this component. this is usually
the path of this component without the first path segment, but can be
overridden by setting the "sling:resourceType".{quote}
As you see in BundleResources we always set sling:resourceType, so we cannot
calculate it using a path. Also components developers need to always set the
resourceType equal to the name of the current folder (without /apps) in order
to make it usable.
2. ResourceMerger
ResourceMerger merges all properties from resources. If you want to overlay
single property, you need to reflect the whole tree with all undeclared
parents. if you won't do it, budle resources will discard all the
sling:resourceTypes from original paths and replace with with either nt:file or
nt:folder.
This is the very simple case of creating an overlay for dialog (adding one
extra tab):
How it is now:
{code:java}
{
"sling:resourceSuperType": "wcm/foundation/components/base-page",
...
"ws:dialog": {
"sling:resourceType": "wcm/dialogs/dialog",
"tabs": {
"sling:resourceType": "wcm/dialogs/components/tabs",
"generalTab": {
"sling:resourceType": "wcm/dialogs/components/tab"
}
}
}
} {code}
how it should be:
{code:java}
{
"sling:resourceSuperType": "wcm/foundation/components/base-page",
...
"ws:dialog": {
"tabs": {
"generalTab": {
"sling:resourceType": "wcm/dialogs/components/tab"
}
}
}
} {code}
...
To solve both of the problems, we need to be able to declare a BundleResource
with no sling:resourceType property, what is not possible now.
> BundleResource fallback sling:resourceType should be consistent with
> JcrNodeResource
> ------------------------------------------------------------------------------------
>
> Key: SLING-11504
> URL: https://issues.apache.org/jira/browse/SLING-11504
> Project: Sling
> Issue Type: Improvement
> Affects Versions: Bundle Resource 2.3.4
> Reporter: Michal Cukierman
> Priority: Minor
> Attachments: Screenshot 2022-07-29 at 17.35.04.png,
> image-2022-07-29-16-47-41-320.png
>
>
> *Background:*
> We work on Sling based CMS -
> [https://www.websight.io|https://www.websight.io/] . One of our current goals
> is to move /apps and /libs folders into bundle resources and get rid of JCR
> based sling scripting and configurations (JCR Installer). This is an
> alternative approach to CompositeNodeStore usage in order to support
> containerized environments, blue-green deployments, and separation of code,
> configuration, and data.
> To achieve this, we move components (and dialogs) definitions from JCR into
> bundles and make them work with the same APIs (like Sling Resource Merger).
>
> *The problem:*
> JcrNodeResource and BundleResource use different mechanisms for calculating
> fallback sling:resourceType
> * In JCR, Resource.getResourceType method is used to calculate resourceType
> if no explicit property is found in the repository. See
> [https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/72c105d67adc58ef1f4d43de78815fdcebb290b5/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L120]]
> * In Bundles, sling:resourceType is always set in the constructor and later
> overwritten by the JSON properties, if available. See:
> |[https://github.com/apache/sling-org-apache-sling-bundleresource-impl/blob/master/src/main/java/org/apache/sling/bundleresource/impl/BundleResource.java#L91]
> It results in a different contract, in particular, it’s impossible to declare
> BundleResource with no sling:resorurceType property. The result can be
> observed in the following Groovy Script execution, where both nodes have no
> sling:resourceTypes declared:
> !image-2022-07-29-16-47-41-320.png|width=751,height=545!
> Incompatible BundleResource and JCRNodeResource contracts requires
> workarounds in multiple APIs (our internal APIs / SlingResource Merger API)
> or to do workarounds at the data level.
>
> *Proposed solution:*
> I can reimplement BundleResource, so that sling:resourceType is calculated in
> the getter. This will result in a valid getResourceType() method contract
> with the possibility of having null sling:resourceType resource property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
