This video teaches us about the kosConfigProperty decorator, which is used in models to get easy access to backend configurations modeled via the Config Service.

See how the configuration properties SDK can make it easy to display configuration data and have them automatically update in the UI whenever they change in the backend.

Let’s take a look at how we can use configuration properties and configuration beans in the model framework.

So configuration properties are a common pattern that you see on the backend, where you have certain objects or certain handles in the backend model that require some data, some configuration data.

Configuration properties provide a really convenient way to expose this data while ensuring that they have persistence and notifications and all of the plumbing that’s required to maintain this data in the context of one of the objects in the backend.

So you see this a lot, and we want to make sure that the KOS model framework had first class support for these configuration properties, because it becomes really common to use these as things like feature flags or configuration parameters that you might use in an administrative UI.

So let’s take a look at how we can use configuration properties, how we can see them in Studio and make use of them in our code.

So to begin with, we already created our model that’s going to hold our configuration data.

Let’s say we wanted to keep track of the selected region, for example, that we’re working in.

So we’re going to use the concept of regions in the UI.

So these are be it countries or territories or whatnot.

We want to be able to have a configurable way of saying what region we’re operating in so that we can do things like provide localization or unit conversion or any of the things associated with different territories or regions.

So let’s take a look first off at Studio.

We can get a sense of how we can identify and discover what configuration properties are there and how we can use them in our code.

So we pull up Studio.

We have our running simulator, our running image here.

And one of the tools that’s available, you can say start a new tool, and you can pick the configuration viewer.

And this is going to run against that image.

And you can see down the left-hand side, all of the handles within the system.

There is a hierarchical path that allows us to see what’s available and what configuration options are available at any given point.

So here’s a good example where underneath the path of KOS service region, there is a region ID.

And it’s saying we’re currently in US East.

And what that’s driving is a number of configurations across the system, including date and time formats and specifying what the default units of measure are for that particular region.

So the details of that will become clear as we go through this.

But for now, let’s just say we wanted to create something that can capture and reflect back to the user what the selected region ID is, which is what’s captured in this property here.

So we can do that by, first off, we’re going to need two pieces of data to get this information.

We need the path for the configuration being itself.

And then we need the ID for the attribute that we’re specifically looking for.

So we can start off by copying the path for the KOS service region handle.

And in our code, we have our configuration details model.

To make use of this, we can start off in our interface.

And we’ll say we want to get the region ID.

And this is going to be a KOS config property.

And it’s generic, so we’re going to say it’s a string.

To use this in our model, there’s two pieces that we need to declare it.

So I’m going to have my region ID, which is a KOS config property.

And there’s a decorator that allows us to get access to it.

So I can say I have my KOS config property.

And this takes one parameter, which is an object.

In this case, I have the path and the attribute, which we said was the region ID.

And that’s really all there is to make use of this, generically, right?

So I can, you know, so in the background, it’s going to, when this model is instantiated, it effectively declares a dependency on the configuration beam.

It’s going to go fetch the data, take the value and inject it into this parameter on the model.

And so by the time the model is ready, we can be assured that the region ID has been fetched.

Its value is available to us as part of a config property.

Now, how we make use of that config property, I can show you in the UI.

So we’ve already created a location for our configuration details view, where we’re putting in the config details with the ID.

So now we can just say we want the region ID, and there is a convention with config properties where we get either the value or the display value.

And we’ll look at display value when we look into unit conversion and formatting.

But for now, the value just provides us the raw value stored in this parameter.

So when I reset, you can see that the config detail is now holding US East.

That itself is fine, but what does this give us?

We’re now getting a value off of this, but in terms of the benefit you get by using the configuration property, is that if I were to go back into the tool and change this from US East to US West, when I change it, you can see that in real time, the UI is updating automatically.

So all of the plumbing associated with moving from listening for the events and propagating them to the model and updating the UI is all handled just by virtue of the fact that we are declaring it as a configuration property.

So all the other details are provided by the framework.

So it becomes an incredibly important tool for you, especially when you’re looking at some of the UIs where there’s large quantities of these configuration properties.

You can create clusters of these views that are just going to maintain that data and you don’t need to worry about whether it’s up to date because the framework will be handling that on your behalf.

Thanks.

Bye.