Name: Working with Widget Controllers in Backoffice Framework in SAP Commerce Cloud
Uploaded: 2021-4-14
Duration: 518 s
Description: This video will guide you through the various view layer options for widgets and illustrate how to alter your widget's functionality by modifying the widget controller within the Backoffice Framework.

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><div><div>This video will guide you through the various view layer options for widgets and illustrate how to alter your widget's functionality by modifying the widget controller within the Backoffice Framework.</div></div></div></div></div>

Working with Widget Controllers in Backoffice Framework in SAP Commerce Cloud

Hi, my name is Lily. In this video we'll talk about the options for the view layer of the widget. We'll discuss the two ways of declaring the visual elements of a widget. And we'll touch on the recommended design pattern to use for the view. After the view, we'll discuss how to change your widgets functionality by modifying the widget controller. Let's start with widget views. The Backoffice Framework support two design patterns, Model View Controller, MVC, and Model View ViewModel, MVVM. The MVC pattern is Backoffice Framework's recommended way of creating widgets. Therefore, in this module, we'll focus on the MVC approach. There are two main reasons for the MVC recommendation. MVC is used by all the widgets in the standard widgets library. And MVC provides better performance than MVVM, .zul files can be used for constructing the user interfaces of widgets and other components. The .zul file originally comes from the ZK framework, which we've mentioned in one of the core frameworks of Backoffice Framework, the contents of the .zul files are first parsed on a JAVA-based web server and then sent a request to a client web browser. .zul files are formatted in a similar manner to XML files, which means that you can open them using a standard source code or text editor. If you open an existing .zul file, you will notice some ZK-specific, XML-like elements within the file. You can also use Java to manipulate the user interface of a widget from within a controller. Let’s take a look at a sample java code snippet to see how we can manipulate a widget's user interface with Java. Here we are showing how to add a new user interface element to the view through Java. The ExampleWidgetController contains a member variable representing the div element called mainDiv in the *.zul file. It is important that the ID of the element in the zul file and the name of the member variable in the java code is exactly the same. This is because the Backoffice framework uses convention to automatically inject the element from the zul file into the Java code member variable with that exact same name. We can see an addButton method that does three things. First, it clears all of the child elements of the mainDiv element so that we are not manipulating existing UI elements. After that, it creates a new button and then adds the button to our mainDiv element. We saw an example of a controller in the previous slide. There are a few more important aspects to controllers that we want to mention. To add a controller for a widget, you will need to extend DefaultWidgetController in your controller class. Additionally, it's good practice to create a unit test right after creating a controller. Even better in the spirit of test-driven development, create your unit tests before actually writing your controller. For a basic unit test, you just need to extend AbstractWidgetUnitTest in your test class. This will provide you with coverage for most of the basic elements, such as sockets, commands, view events, global events, and a null-safe check executed against all declared inputs of the widget. Once we have our widget controller created, we can then create methods for the controller to interact with the view. Here you can see the controller has a getRandomNumber() method. Controller methods can easily be accessed in the zul files using EL (expression language) syntax. An EL expression is an expression enclosed with "$", "". On the screen, you can see the expression is referring to the getRandomNumber method from the controller called WidgetController. When the view displays, it will set the label of that element to whatever values returned from the WidgetController getRandomNumber method. Within a controller, there are multiple types of widget data which we can access. One of these types is model data. Here we can see two ways of storing a value in the widget's model. In both cases, we are storing the productModel object using the "product" key. The main difference between these two storage methods is with notifications. The setValue() method notifies observers about the change. The put() method does not provide notifications. The widget's model data can also be retrieved in zul files using EL expressions. in XML files using EL expressions. Remember that an EL expression is an expression enclosed with $. So if we put 'widgetModel.product' into an EL expression, this tells the application that we want to retrieve the value of the property with key "product", for the WidgetModel object. We can also retrieve model data in Java code with the getValue method. This method takes in two parameters. The first parameter passed to the method is the key for the value we wish to retrieve. The second parameter is the type of object we are retrieving. We can also retrieve a widget's settings in our view file. Remember that a widget's settings are the XML elements listed within the  tags in the definition xml file. To retrieve a widget setting, we use an EL expression, starting with "widgetSettings", and after a dot we specify the key that is the name of the setting. In the java code, we can use the getWidgetSettings() method, and on that we call one of available getters depending on the type we want to retrieve. Options can include getString, getInt, getDouble, or getRaw if we want to retrieve a raw Object instance. Regardless of the getter that we use, we need to provide the “key” String as a parameter. In this example, our key is “displayButton”. This returns a true or false value. If we want to access a static resource in a zul file, we need to use the $ expression. This stands for "absolute web path", which in our case means the widget root of the widget definition file. For example, if we have a favicon.gif and default.css file on the same level as the widget definition xml file, we will need to use $/favicon.gif and $/default.css respectively to access them. You can create localized labels for multiple languages for your widget. These labels will go in the labels directory within files that follow the naming convention of labels.properties for the default labels and labels_.properties for language-specific labels. For example, for German, the labels would go in labels_de.properties. labels_es_CO.properties would hold labels for the Spanish locale in Colombia. Each label within the property file is defined using a specific convention. The label should use all lowercase letters. The label should also show its hierarchy in the context of the application by using dot as a delimiter for the label keys. The label’s value is then placed after the equal sign. You can access a label from both the zul file and from the controller. In the zul file, to access a label you will use the EL syntax, $, where KEY is the name of the label. In our example, the key is item.saved. In the controller, you can access a label with the widgetInstanceManager’s method, getLabel(), which takes the label's key string as a parameter. In this video, we discussed the most essential topics about widgets. We talked about the design patterns that you can use with your widget view. We went over how you can set up and manipulate a widget's view from both its zul and its controller. Finally, we discussed how you can access widget data from both its zul and controller files. Widget data you can access includes controller methods, model data, widget settings, static resources, and localized labels. Thanks for watching.