Dan,
I am in favor of adding the features from ddr to sling-superimposing -
is that ok for others too?
Ruben
On 4/20/2021 4:14 PM, Daniel Klco wrote:
IMO the biggest difference is how this defines the root of the dynamic
resources, e.g. via creating a resource at that path or providing a
configuration with the source and target. This alone is a major advantage
as it means that ddr configurations can be defined at runtime with a
composite store.
The problem I see here is that we are trying to solve the same problem
multiple ways.
My take on the problem is:
As a developer or superuser, I want to be able to present a virtual tree of
resources generated from a tree of resources and a configuration tree.
Resource merger solves this problem by anchoring a root and then defining
source paths which can be overlayed and configured in order. This works
well in the case where you have only two trees and you want to present a
merged copy of these two trees, but does not work for arbitrary anchor
points.
Superimposing supports creating arbitrary roots but these roots can only be
tied to one source. It also only allows overriding the overlayed resouces
by using a lower level api (such as JCR) because the sling post servlet
will update the source resources.
Generally, I think it's better to have fewer ways of doing the same thing,
do it makes sense to consolidate if possible. Given that resouces merger is
widely used, I can't see how it would be worth the effort to regression
check potential breaking issues. However, given that SuperImposing has not
been significantly updated in years, I would recommend that we:
1. Update SuperImposing to work on Java 11 / OSGi 6 / Sling 12
2. Update SuperImposing to support defining virtual trees by source and
source+target and other DDR features
3. Define a feature model to install the bundle and create an oak index for
the mixin
4. Release this as the 1.0 version of SuperImposing
I've already taken a run at updating SuperImposing and am ~75% there.
What do others think?
-Dan
On Tue, Apr 20, 2021, 5:34 PM Andreas Schaefer <schaef...@me.com.invalid>
wrote:
Here is a short recap after trying to compare Superimposing Resource (SIR)
and the Declarative Dynamice Resource (DDR). They are similar in some
respect and different in others:
Feature SIR DDR
Resource Resolver type Admin RR Service RR
Linking from Target Source
Mixin Supported Not
Supported
Resource Changes Supported Supported
Property Changes Not Supported Supported
Configure Parent by
1st Level Child Supported Not Supported
Overlays Supported
Not Supported
2nd Level Redirection Not Supported Supported
Filtering (Security) Not Supported Supported
Java 11 Not Supported Supported
Sling 12 Not Supported
Supported
Cheers - Andy
On Apr 20, 2021, at 6:13 AM, Stefan Seifert <stefan.seif...@diva-e.com.INVALID>
wrote:
hello ruben.
use case sounds a bit similar to
https://github.com/apache/sling-org-apache-sling-superimposing (a bit
outdated)
and
https://github.com/apache/sling-org-apache-sling-resourcemerger
can you differentiate what DDR does differently?
stefan
-----Original Message-----
From: Ruben Reusser <r...@headwire.com>
Sent: Tuesday, April 20, 2021 1:54 PM
To: dev@sling.apache.org
Subject: Re: Sling Declarative Dynamic Resources
totally forgot to add the link to the code base - sorry
https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr
On 4/19/2021 10:29 AM, Ruben Reusser wrote:
dear sling community
Andreas has been working to create a way to dynamically create
component proxies in Sling based on a configuration. In peregrine-cms
we are planning to use this approach when a new tenant (a new website)
is created by a user. It allows us to proxy the base components into a
new /apps folder for the website. A super user for the site can then
potentially change the title/group of a component and the default
structure that is used when adding a component to a page.
We hope this component may be useful to other sling based content
management systems as well. We'd like to ask to move this module out
of the whiteboard - but of course we welcome any
comments/concerns/things we should consider to make sure everybody can
benefit from this module.
looking forward to your comments!
Ruben
