Service Portal widgets
How a widget is built: server script, client controller, HTML template, options and data flow.
How a widget is built: server script, client controller, HTML template, options and data flow.
- data carries server results to the client, input carries client requests back
- Option schemas make widgets reusable across pages
- Keep the server script lean, it runs on every load
- Use existing widgets as a base before writing a new one
The three parts
A widget has a server script that runs once and fills the data object, an HTML template rendered by AngularJS, and a client controller that handles interaction. The data object is the bridge between server and client.
Server to client and back
The client calls the server again with c.server.update() or c.server.get(). Anything on input arrives in the server script as input, and anything on data returns to the client.
// server script
data.openCount = new GlideAggregate('incident');
// ...
if (input && input.action === 'refresh') {
data.refreshedAt = new GlideDateTime().getDisplayValue();
}
// client controller
c.refresh = function() {
c.data.action = 'refresh';
c.server.update().then(function() { c.data.action = undefined; });
};Options and reuse
Declare an option schema so the same widget can be dropped on several pages with different titles, tables or filters. Hard coding a table name inside a widget is the fastest way to end up with five near identical widgets.
Performance
The server script runs on every page load. Keep queries narrow, use GlideAggregate for counts, and avoid loading a hundred records to show five.