What would be the right way to avoid the execution of code that is intended for Classic Dialogs, and not for Touch UI ? | Community
Skip to main content
jydps87387977
jydps87387977
Level 3
March 7, 2016
Solved

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

  • March 7, 2016
  • 6 replies
  • 1426 views

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 ?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by smacdonald2008

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. 

6 replies

Lokesh_Shivalingaiah
Lokesh_Shivalingaiah
Level 10
March 7, 2016

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
Lokesh_Shivalingaiah
Level 10
March 7, 2016

Can you give more details on your usecase

Kunal_Gaba_
Kunal_Gaba_
March 7, 2016

You can try the following-

if (typeof CQ.WCM.MODE_EDIT == "undefined") { //Touch UI } else { //Classic UI }
jydps87387977
jydps87387977Author
Level 3
March 7, 2016

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
smacdonald2008Accepted solution
Level 10
March 7, 2016

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
Lokesh_Shivalingaiah
Level 10
March 8, 2016

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.

Terms & ConditionsAccessibility statement

Loading footer...