Name: Defining the Widget Structure in Backoffice Framework in SAP Commerce Cloud
Uploaded: 2021-4-16
Duration: 319 s
Description: In this video, you will be introduced to widget folder structures. You will learn about the physical structure of a widgetdefinition.xml file, its setting options, and restrictionstwo ways of declaring the visual elements of a widget

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div>In this video, you will be introduced to widget folder structures. You will learn about <br><ul><li>the physical structure of a widget</li><li>definition.xml file, its setting options, and restrictions</li><li>two ways of declaring the visual elements of a widget</li></ul></div></div></div>

Defining the Widget Structure in Backoffice Framework in SAP Commerce Cloud

Hi, my name is Lily. In this video, we'll discuss the physical structure of a widget, meaning how it's structured on your file system. We'll discuss the definition XML file and its setting options and restrictions. We'll discuss the options for the view layer of the widget, and we'll discuss the two ways of declaring the visual elements of a widget. Throughout this video, I'll show you examples from actual widgets in cockpit and standard widgets library. Let's start with the simplest possible physical structure for a widget. A widget structure on the file system can contain various files and file types, but the one requirement is that it contains a definition XML file in which a unique ID for the widget is defined. Here's an example of an existing definition XML file within the resources folder for the authority group selector widget. A widget from the standard widgets library similar to this. Each one of your widgets should be defined under the Resources Widgets folder within a folder of the same name as the widget. Most pages will contain these three files on the system. Would your definition also known as definition XML? Here, component interfaces. For example, inputs and outputs are defined along with other metadata info such as the controller class view file author a name. The widget view is the second file a widget will contain. It has the extension dot XL. The view contains standard XML syntax with added high res tags. It requires no compiling, it only needs to be changed, and then the browser shows changes after the browser has been refreshed. The third file is a controller. This is a Java class containing business logic. It has standard syntax allowing you to react to socket and user interface events. Technically, elements such as controllers, view files, localised labels, and other static resources like images and CSS files are optional. They are not required by the cockpit Ng framework. You may require some of these optional elements for a widget to function properly according to your business requirements though. Here you can see a snapshot of a folder structure that contains the authority Group selector widget definition along with the widgets controller view file, localised labels, and other static resources. Here's an example of a widgets definition XML file. Remember that the widget ID must be unique. If the widget ID is not unique, the widget will not appear on the list of widgets in the choose Widget Wizard from within Application orchestrator. This means that you will not be able to add your widget to your application measure. Similarly to Java packages. We recommend that you integrate at least your company or customer name and project name into the widget ID, in order to minimise the potential for ID conflicts in the widget definition XML. We can optionally define the widgets metadata. This can include the widgets name, description, default, title, author and version. In the widget definition XML, we can optionally specify a controller for our widget so that it can respond to user interface events and socket events. To do this, we use the controller XML element, which has a class attribute that points to the fully qualified name of the Widgets controller class. We can also specify the view file for the widget using the XML view element. Here we can see that the view file is in a file called default tab widget. One thing to note is that if the XML view element is not provided in the definition XML. The back office framework automatically looks for a view file with the same name as specified in the last part of the widgets id attribute. The part after the package. In this example, if the view element had not been explicitly defined. The framework would search for a view file by the name of default ab widget. The optional widget input and output sockets get configured in this file. Where you can provide an ID and a required type for each socket. The key word XML element is for providing a category for your widget. This keyword value is used in Application Orchestrator as a category to group widgets by. When selecting a widget. To add the application mashup. Another optional section of the definition XML is for widget settings. Here you can define what settings are available for your widget and provide any default values for these settings. The name of the settings specified in the key attribute, and the default value specified in the default value attribute. Administrators can modify setting values for a widget instance at runtime through the user interface in Application Orchestrator. In this video, we discuss the physical structure of a widget, meaning how it's structured on your file system and how to define the structure via the definition XML file. Thanks for watching.