You know; I wasn't able to find much of anything documentation wise that references this feature, other than it happens to exist. I think it became one of those things that someone either told you about, you figured out by accident, or never even knew existed over the the years.
I assume you may have some questions about it, so I'll outline what I know and others might chime in as well.
The Widget Editor is the only place that the Demo Data will come into play: Demo Data is completely ignored in the Portal Designer, and at Run Time.
Essentially, if you define a JSON object in this field for data (or options) then, in the widget editor the client controller will use the Demo Data that you have defined onload, and not the data object from the Server Script.
If your client controller places a call to the server (get or update) then the demo data will potentially be replaced with the current server data (assuming you refresh those parts of the object, or the whole data object).
Why would use this feature? Obviously, this could be useful once you are done with development to set some static values - literally - to demo the widget in the editor, passing in exactly what you want to display.
During development I'd say 90% of the time, you wouldn't bother. Typically you want to see the dynamic data while you are developing. Where this is useful however is in situations where you are developing something that uses dynamic input that might not be available in the widget editor, such as pulling a sys_id or other value from a URL parameter (think, for example the SC Catalog Item widget that pulls in the catalog item from the URL). Using Demo Data you can populate a value to simulate what you would expect from a portal page - makes life a little easier than the whole "edit, save, reload in portal" approach.
One other instance where this is useful is when you are developing a widget with options. Since you can't define the options until you have an instance of the widget (other than hard-coding values), demo data gives you a way to test out different scenarios in the widget editor as you can include an options object along with the data object (or individually, in either case).
This is kind of a cheesy example, but this is a sample widget that helps demonstrate the functionality:
HTML Template:
<div>
<p>{{data.demo}}</p>
<p>{{data.noDemoData}}</p>
<p>{{options.demoOption}}</p>
<input id="refresh" class="checkbox" type="checkbox" ng-click="c.update()">
</div>Server Script:
(function() {
data.demo = 'Live Data from the Server!';
data.noDemoData = 'Now you see me!'
if(!options.demoOption) {
options.demoOption = "Replaced by Server";
}
})();Client Script:
api.controller=function() {
var c = this;
c.update = function() {
c.server.get().then(function(r) {
//Here we call the server for an update and
//replace the data and the options
c.data = r.data;
c.options = r.options
});
}
};Demo Data:
{
"data":{
"demo":"This is demodata"
},
"options":{
"demoOption":"This is a demo option"
}
}
What you see in the Widget Editor onload:
And then when you click the box (triggering an update from the server)
If you have the widget on a page and load it, you go right to the end result, without the checkbox needing to be checked:
Hopefully that helps demystify this (mostly) undocumented feature.
I hope this helps!
If this was helpful, or correct, please be kind and mark the answer appropriately.
Michael Jones - Proud member of the GlideFast Consulting Team!
You know; I wasn't able to find much of anything documentation wise that references this feature, other than it happens to exist. I think it became one of those things that someone either told you about, you figured out by accident, or never even knew existed over the the years.
I assume you may have some questions about it, so I'll outline what I know and others might chime in as well.
The Widget Editor is the only place that the Demo Data will come into play: Demo Data is completely ignored in the Portal Designer, and at Run Time.
Essentially, if you define a JSON object in this field for data (or options) then, in the widget editor the client controller will use the Demo Data that you have defined onload, and not the data object from the Server Script.
If your client controller places a call to the server (get or update) then the demo data will potentially be replaced with the current server data (assuming you refresh those parts of the object, or the whole data object).
Why would use this feature? Obviously, this could be useful once you are done with development to set some static values - literally - to demo the widget in the editor, passing in exactly what you want to display.
During development I'd say 90% of the time, you wouldn't bother. Typically you want to see the dynamic data while you are developing. Where this is useful however is in situations where you are developing something that uses dynamic input that might not be available in the widget editor, such as pulling a sys_id or other value from a URL parameter (think, for example the SC Catalog Item widget that pulls in the catalog item from the URL). Using Demo Data you can populate a value to simulate what you would expect from a portal page - makes life a little easier than the whole "edit, save, reload in portal" approach.
One other instance where this is useful is when you are developing a widget with options. Since you can't define the options until you have an instance of the widget (other than hard-coding values), demo data gives you a way to test out different scenarios in the widget editor as you can include an options object along with the data object (or individually, in either case).
This is kind of a cheesy example, but this is a sample widget that helps demonstrate the functionality:
HTML Template:
<div>
<p>{{data.demo}}</p>
<p>{{data.noDemoData}}</p>
<p>{{options.demoOption}}</p>
<input id="refresh" class="checkbox" type="checkbox" ng-click="c.update()">
</div>Server Script:
(function() {
data.demo = 'Live Data from the Server!';
data.noDemoData = 'Now you see me!'
if(!options.demoOption) {
options.demoOption = "Replaced by Server";
}
})();Client Script:
api.controller=function() {
var c = this;
c.update = function() {
c.server.get().then(function(r) {
//Here we call the server for an update and
//replace the data and the options
c.data = r.data;
c.options = r.options
});
}
};Demo Data:
{
"data":{
"demo":"This is demodata"
},
"options":{
"demoOption":"This is a demo option"
}
}
What you see in the Widget Editor onload:
And then when you click the box (triggering an update from the server)
If you have the widget on a page and load it, you go right to the end result, without the checkbox needing to be checked:
Hopefully that helps demystify this (mostly) undocumented feature.
I hope this helps!
If this was helpful, or correct, please be kind and mark the answer appropriately.
Michael Jones - Proud member of the GlideFast Consulting Team!
