Using the configuration of the Smart UI widget
In this post, I will build on the project we built here. In this article, I will take you through:
- Creating some configuration elements on the property screen (that can be updated via the Perspective Manager)
- Read in those properties
- And pass those properties from the View down onto the Model Factory, and final down to the Model.
The Setup
What we are aiming for is a Smart UI widget that:
- Can set the debug level on the widget via the Perspective Manager
- Read in those settings and cascade that setting from the View down to the Factory and the Model.
This can be helpful in troubleshooting. In an ideal world, you wouldn't need to log out to the console because everything is perfect — but it's not so here we are.
Now it is worth noting that there are already many logging options within the Smart UI SDK framework — this is something that I rolled out for demo purposes.
The Logger
In my project’s src folder I have created a new folder called logger and within that, I have created a JS file called …. logger.js
This has been written in the require.js style. But as you can see it has:
- a config method that will enable you to set the mode and the appname (we will use this to make sure we are logging out from the right levels in the module)
- A debug method to log out debug events
- a log method that will only log out if the log mode is either DEBUG or INFO
- an error method that will always log out an error
- And finally a logit method that will take the inputs and format the log requests
Adding properties
To add properties that can be accessed via the Smart UI you will need to update the manifest.json file for your project.
To extend this we need two elements:
- The schema needs to be extended to create a container for our options
- And given that we are providing a drop-down, we need some fields to be rendered
Beware that your options in your ‘optionLabels’ property (under options) need to be written in the same order as the enum property in your schema property.
Smart UI SDK limitation
The Smart UI SDK does not contain a mock Perspective Manager. So the first that you will see this working is in the compiled module — so if you are keen you might want to drop down an intermediate build at this stage so you can see this displayed.
The View
With the properties sorted we now need to bring this into our view. The first thing we will do is to import this. We do this by adding the path of the import which in this case is:
'dlmod/logger/logger'Next we need to import the corresponding variable into the callback function
function (_, Marionette, HelloModelFactory, dlLogger, lang, template)
With this enabled, we can add this to our view
Next, we need to initialise the logger — we do this in the constructor method. However again because we don't have a perspective manager in our Smart UI SDK providing properties we need to be a bit defensive in our approach and set some sensible defaults.
var debuglevel = 'NONE'; // Default Log Level// Check if there are any options being passed in from perspective managerif (options.hasOwnProperty('data')) {
debuglevel = options.data.debug || 'INFO';
} else {
debuglevel = 'NONE';
}// Set the log level of the logger
this.logger.config(debuglevel, 'HelloView');
Finally, we add some test logging lines to make sure everything is working
this.logger.log('Logging with a log level of ' + debuglevel);
this.logger.debug('Debug with a log level of ' + debuglevel);
this.logger.error('Error with a log level of ' + debuglevel);
You will note that since the log level has defaulted to none, only the error is logged out.
The Factory
Our next challenge is to pass this logging information down to the factory.
Update View
This is a simple affair in your view you are looking for line of code like this:
options.model = options.context.getModel(HelloModelFactory);The getModel method allows a second parameter called options. Using this we can pass the log level to the factory:
options.model = options.context.getModel(HelloModelFactory, {loglevel: debuglevel});
Update the Factory
Like the view will import our logger and set our logger attribute
Next, we update the constructor to :
- Read in the options from the view
- And update the config of the logger for the factor
And again we will be defensive and add some defaults.
And as before we add some sample logging events.
And sure enough in our local Smart UI SDK we have our logging events.
The Model
Updating the model is very similar.
Update Model
As with the Factory and View we import the logger, and set the attribute
And as with the Factory, we will set some sensible defaults and configure our logger.
Update Factory
Finally, we update the factory to ensure that we are passing the log level down to the model. To do this we look for the initialisation of the new Model, and pass in another attribute to the options:
which leaves the Factory looking like this:
Build and Wrapping up
With everything in place, we are now in a good place to build out our project.
In the demo above we load the widget view — edit the page — change the log level — save the changes and have the logging display in the console.
I hope this piqued your interest — a big thanks to Reiner Merz for pointing me in the right direction to find where the properties are stored. Everything was done by reverse-engineering the base Smart UI widgets. Hopefully, the documentation will improve over time, but in the meantime enjoy this 😁
