Highlighted

Get runmodes value in client-side JS

hanscy

15-03-2019

Hi guys,

is there a way in AEM to get a value from AEM runmodes in client-side JS?

I have a key value that is changing depending on the environment, it needs to be on client-side JS since it is calling a widget integration.

Thanks before!

Replies

Highlighted

Veena_Vikram

MVP

15-03-2019

The runmode values are something you can get either via server side Java API or using Server Side JS.

Now I don't know if this is the right way to do it , but one thing what is coming to mind right now is to add the runmode as a hidden value in an html element in your page and then using the client side JS , fetch value from the element . I would really love to see other expert opinion on this .

Highlighted

Arun_Patidar

MVP

15-03-2019

Hi,

To manage/configure run mode specific value, you should use run mode osgi configuration and read key value using model.and store either in HTML hidden element or JSON object or use it if applicable. It will remove the extra run mode check overhead.

But if you want to check run mode, you have to go with server side JS Api or Java.

e.g.

template.html

<div data-sly-use.head="logic.js">

<p><b>Modes :</b> ${head.runmodes}</p>

<p><b>Is This author :</b> ${head.author}</p>

<p><b>Is This Publish :</b> ${head.publish}</p>

</div>

logic.js

var SlingSettingsService = Packages.org.apache.sling.settings.SlingSettingsService;

use(function () {

    // Get runmodes and transform them into an object that is easier to read for Sightly

    var runmodesObj = {};

    var runmodesSet = sling.getService(SlingSettingsService).getRunModes();

    var iterator = runmodesSet.iterator();

    var isauthor=sling.getService(SlingSettingsService).getRunModes().contains("author");

    var ispublish=sling.getService(SlingSettingsService).getRunModes().contains("publish");

    while (iterator.hasNext()) {

        runmodesObj[iterator.next()] = true;

    }

   

    return {

        runmodes: runmodesObj,

        author: isauthor,

        publish: ispublish

    }

});

Highlighted

Gaurav-Behl

MVP

15-03-2019

Use 'wcmmode' or 'cq-authoring-mode' cookie per your use case. Add appropriate null/undefined checks in place.

Highlighted

Jörg_Hoh

Employee

15-03-2019

The runmode is an implementation detail, and you should tie your JS code directly to that. Instead set config value with OSGI configuration, and expose the value of this configuration somehow (render it into a page or via JSON).

Highlighted

hanscy

17-03-2019

Thanks Jörg!

when you said render it into a page? do you mean put it on the HTML as a hidden as what @Veena_07 ​stated?

Highlighted

hanscy

17-03-2019

Hi Veena!

Exactly I was thinking the same way as you do putting it on HTML as a hidden value. However I don't really feel that it is very correct approach

Highlighted

Arun_Patidar

MVP

18-03-2019

Hi,

I don't think so there is any harm if you want to expose some value in hidden field or as JSON/javascript variable based on run mode at client side. If you expose all the run mode then that could be the vulnerability.

I would suggest do all the calculation based on run mode at server side and base on outcome set different/boolean variable.

Or store key in osgi config and access directly.

Highlighted

Jörg_Hoh

Employee

18-03-2019

You should not expose the concept of runmodes to your frontend. Instead you should define a marker which is queried by your frontend; and this marker might be rendered directly into the page or queried via JSON. And the presence of the marker in the markup (or JSON) is controlled by an OSGI configuration which can be set via runmode-based OSGI configuration.

Otherwise you need to have knowledge in your frontend about backend specifics.