Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Loading Sightly templates outside of /apps

Avatar

Level 2

Hello

I am trying to implement a feature that would let authors have limited access to Sightly templating. For example, a heading component with a 'text property

- heading.html

<sly data-sly-test.templatePath="${properties.templatePath ? properties.templatePath : 'default.html'}"></sly> <!-- if there is an author template path (in DAM), use it. Otherwise, use default template --> <sly data-sly-use.template="${properties.templatePath}" data-sly-call="${template.myTemplate @ title=properties.title}" ></sly>

- default.html

<template data-sly-template.myTemplate="${@ title}"> <h1>${title @ context='html'}</h1> </template>

The problem is that, for data-sly-call, Sightly can only load files from the Resource Resolver search path. When I try to add another directory like /content/dam/templates there, all hell breaks loose (see image links).

The servlet resolver cannot resolve siteadmin or damadmin servlets.

Question: how to load Sightly template from DAM without destroying my instance?

 

Thanks,

Eli

https://cl.ly/2l2w0y230z1G

https://cl.ly/303j091F2T2z

4 Replies

Avatar

Level 8

I have to ask, why on earth would you want to give authors access to something that could potentially take down their site?  Seems like a really bad idea.

Avatar

Level 2

Our company requires very flexible authoring. Our dev team can take down the site with a template as well. I am working on this as a pilot, to be used in a restricted context by a few authors

That being said, are you thinking about a scenario where this will happen by mistake?

Avatar

Level 10

This structure looks wrong. Templates under /content/dam is not great practice. AEM best practices typically places templates under /app.

Avatar

Level 8

Well the difference there is that they're developers and should know what they're doing.  Any code changes by a developer should probably also go through a QA process.  

Giving an author, whom we have to assume knows nothing about coding/html control over code that gets compiled, in any environment, but especially in Production seems like a really bad idea.  A missing single quote, accidentally deleting a curly bracket or even just misspelling something like "context" would bring the site down instantly.

What's the use case for flexible authoring?  What about the component would the author need to change for it to be considered flexible?