Detecting Touch UI or Classic UI Modes in HTL (Sightly)

[Matt-H-]

Hello,

We are using AEM 6.3, and I'm trying to detect if the mode is Touch UI or Classic UI.

I've tried following https://wcmaem.blogspot.com/2016/07/how-to-check-touch-ui-mode-in-sightly.html. But it is not working in Touch UI.

My code:

<p>Text before</p>
<sly data-sly-use.wcmModes="/libs/wcm/foundation/components/page/initwcm.js"></sly>
<p>Text in between</p>
<div data-sly-test="${wcmModes.wcmmode.edit}"> Classic Edit Mode </div>
<div data-sly-test="${wcmModes.isTouchAuthoring}"> Touch Edit Mode </div>
<div data-sly-test="${wcmModes.wcmmode.design}"> Design Mode  </div>
<div data-sly-test="${wcmModes.wcmmode.disabled}"> Disabled mode </div>
<p>Text after</p>

In Classic UI, it works as expected, showing "Text before", "Text in between", "Classic Edit Mode", and "Text after".

In Touch UI, not only does "Touch Edit Mode" not show up, neither does "Text in between" or "Text after". The rendering stops once it hits the <sly> statement.

Any ideas why or what I would need to do to get it to work? Thanks!

[arunpatidar · Accepted solution]

Hi,

you can use OOTB(/libs/wcm/foundation/components/utils/AuthoringUtils.js) utility to identify editing mode.

<sly data-sly-use.authoringuimode="/libs/wcm/foundation/components/utils/AuthoringUtils.js" >

  <p>${authoringuimode.isTouch}</p>

    <p>${authoringuimode.isClassic}</p>

</sly>

[Feike_Visser1]

for the main-modes I would go for ${wcmmode.edit}, no need for extra libs

[arunpatidar]

Yes Felix, I would also go for same if need to just identify wcmmode using global object 'wcmmode'.

[Matt-H-]

When I use ${wcmmode.edit}, it evaluates to true both in Classic and TouchUI.

I appreciate the answer:

<sly data-sly-use.authoringuimode="/libs/wcm/foundation/components/utils/AuthoringUtils.js" >
<p>${authoringuimode.isTouch} </p>
<p>${authoringuimode.isClassic}</p>
</sly>

That normally would have worked for me. But the component I'm working with, I'm trying to use it in two contexts - one is in Classic UI, but the other is in the Page Properties dialog box, and ${authoringuimode.isTouch} apparently evaluates to false (and ${authoringuimode.isClassic} to true) there. I didn't know it made a difference, or I would have included it in the original question.

Through this, I also found out that in my original code, the initwcm.js doesn't bomb out and data-sly-test="${wcmModes.isTouchAuthoring}" evaluates correctly in (regular) TouchUI. (data-sly-test="${wcmModes.wcmmode.edit}" still came up true in both Classic and regular Touch, like ${wcmmode.edit}).

So does anyone know how, in HTL, to detect between Classic UI and the Page Properties dialog box within Touch UI? (If this should be a separate, new question, please let me know.)

[Matt-H-]

Ok, it turns out I need to be careful how I test this.

The code using AuthoringUtils.js does work, if the regular Touch UI page is loaded. But if you bounce back and forth between Touch and Classic in different tabs, the detection is going to get confused. Coming from a (reloaded) classic ui tab, and then reloading straight into the touch ui page properties, it detects it as classic. But when the main Touch UI page is reloaded and then the page properties, it detects it as Touch.

Thank you for your help!

[arunpatidar]

Hi,

its may be because of the detection is cookie based.