I'm trying to understand if I can use the resource overlay concepts and
apply them to static resources. This for a more client side oriented style
of application made with react
I know that I can define something in /libs and a customization as
recommended in /apps. This implies the definition of nodes in /content and
the specification of a resourceType pointing to a path that could be on
/apps (checked first) or /libs (checked last). For this I need to specify
each and every node on /content and rely on the native resource resolution.
I wonder if I can use this concepts but with static resources. Let's imagine
that I have a super simple application with the following base layout
specified in libs:
Then I would like that a customer uses my definition as base but only with a
customization on the css and on the logo
and on content
I know that this is not cleary the intent of the mechanism more geared to
server side components, however for client side applications this could be
very interesting. Is it possible to achieve something like this over the
sling infrastructure ?
Bear with me, maybe I'm missing something super simple or this is simply a
big deviation from the initial purpose of sling but I think the resource
overlaying concept is very powerful much more if coupled with a content
server like sling.
On Sun, 2018-03-04 at 16:15 -0700, ivoleitao wrote:
> Then I would like that a customer uses my definition as base but only
> with a
> customization on the css and on the logo
> and on content
The simplest way I see this happening is via a component. Define a
'layout' or 'logo' component at /libs/my/component and allow the
customer to overlay it at /apps/my/component .
Alternatively, you can write another component and lookup the design
resources using `ResourceResolver.getResource` and a relative path,
which would first look under /apps and then under /libs.
On Mon, Mar 5, 2018 at 8:42 AM, Robert Munteanu <[hidden email]> wrote:
> Hi Ivo,
> On Sun, 2018-03-04 at 16:15 -0700, ivoleitao wrote:
> > Then I would like that a customer uses my definition as base but only
> > with a
> > customization on the css and on the logo
> > /apps/acme/img/logo.png
> > /apps/acme/css/acme.css
> > and on content
> > /content/clientacme
> The simplest way I see this happening is via a component. Define a
> 'layout' or 'logo' component at /libs/my/component and allow the
> customer to overlay it at /apps/my/component .
> Alternatively, you can write another component and lookup the design
> resources using `ResourceResolver.getResource` and a relative path,
> which would first look under /apps and then under /libs.
Something to also keep in mind is that you can define additional search
paths in Apache Sling Resource Resolver Factory. You are not limited to
/apps, and /libs.
You could then have something like /acme or even /apps/acme (I think) as
lookups for resolving relative resources. I would strongly advise against
putting anything in /libs.
Depending on your level of expertise and your exact use case, I would
highly recommend look at using Context Aware Configurations for each tree
where you can specify paths for each context. This is better from a content
delivery standpoint as you could keep your resources all in a similar place
(/content/dam/myLogos) which makes asset and CDN management easier.
without building components for each and every file. What I was thinking was
some way to pick and choose between apps and libs without explicit content
configuration for each and every node.
In the past I've built a custom resource resolver to integrate another
content server with Sling and I'm now wondering if same strategy could be
used with minimal configuration, for instance to configure a node to have
this overlay behavior for each and every child node by specifying only the
root overlaying node or something like that.
Just to update this issue. We solved the problem with a custom
resourceprovider. We are now able to merge static resources in the same way
it's currently possible for sling components. Giving a proper example:
we are now able to mount a resource provider in /content/superacme which
overlays by order /apps/myacme and then /libs/acme
I've changed the names of all the roots on purpose to better explain the
For this example requesting the static data from /content/superacme we end
/content/superacme/index.html <- From apps
/content/superacme/images/logo.png <- From apps
/content/superacme/campaigns/campaign1.html <- From apps
/content/superacme/campaigns/campaign2.html <- From apps
/content/superacme/styles/theme.css <-- From libs
We are using this to provide to our developers a way of overriding the base
frontend app that we are developing, thus providing a way to customize
almost everything from the base definition.
We are planing to introduce a merging concept also for json resources.
As soon as we finish our delivery we can contribute this resource provider
if someone finds this interesting.