What would be the right way to avoid the execution of code that is intended for Classic Dialogs, and not for Touch UI ?

[jydps87387977]

Hi,

I am working with an application components with supporting the Touch UI components dialogs and Classic dialogs.

While using the Touch UI component dialogs, the component rendering jsp is getting executed, and it fails.

I tried having JS with Granite.author the following condition:

if (Granite.author) {
    // touch UI
} else {
    // classic UI
}

Question:  What would be the right way to avoid the execution of code that is intended for Classic Dialogs, and not for Touch UI ?

[Lokesh_Shivalingaiah]

What is the difference in rendering between these two UI ?

Are the properties different in each of these dialogs or just the rendering style ?

[Lokesh_Shivalingaiah]

Can you give more details on your usecase

[Kunal_Gaba_]

You can try the following-

if (typeof CQ.WCM.MODE_EDIT == "undefined") { //Touch UI } else { //Classic UI }

[jydps87387977]

The use case is to have the Touch UI components without affecting the existing classic dialogs.

There is an exisiting jsp that already contains some EXT JS logic for CQ classic dialog population. 

In case of using Touch UI components, this JS code inside existing jsp to be AVOIDED for execution. 

[smacdonald2008 · Accepted solution]

So the main difference between Classic and Touch UI is the dialog nodes. 

A dialog that is built for the Touch UI is defined by using nodes of type un:structured. You define the type of control on the Touch UI dialog by setting the node's sling:resourceType property. For example, to define a text field on a Touch UI dialog, set the  sling:resourceType property to granite/ui/components/foundation/form/textfield.

On other hand - a dialog built for Classic uses xtypes and ExtJS. 

Both are JCR node structures. In Classic, you can code using ExtJS and define custom xtypes. In Touch UI, you can code against the Granite APIs. Both of these APIs are meant for code to run on Author - not Production or in the component application logic. (You cannot run ExtJS code in a component's JSP. You run it in a JS file within a clientlib associated with the component.)

You can see this in this community article: 

https://helpx.adobe.com/experience-manager/using/creating-touchui-component.html

The actual component logic (the app logic that renders the component) is the same for both Touch UI and Classic UI. Both ExtJS and Granite APIs are not meant to run on Production. Therefore they are not used within the component's JSP or Sightly.  

Hope this helps. 

[Lokesh_Shivalingaiah]

As Scott mentioned, same component can support both touch UI and classic UI without any problem. All the JS which needs to be executed by the classic UI should be referenced in the classic UI dialog and I am not sure why that JS would be included in JSP. Rather, keep it as a part of clientlibs and then refer that JS in the classic UI.