Content |
|||||||||||||||||
|
Overview |
|
|
Gizmos are SDIs that define dynamic object-orientated blocks of functionality that can be plugged into different parts of the application to show and expose functionality. For example, Gizmos can be seen in the Layout (most notably in the Menu Bar and Sidebar), Dashboard, and in the full-page rendering of the Group Gizmo. Additionally, new Request Controller commands allow full page rendering of a Gizmo through the URL (such as rc?command=gizmo&gizmo=xxx, where xxx is the Gizmo SDI Keyid1).
Gizmos also support DBMS-specific property values (see Web Page Designer → Properties Overview → DBMS-Specific Property Values).
Adding Gizmos |
|
|
General Procedure |
Gizmo SDIs are based on Gizmo Types. These are "base types", in that you do not directly reference them. You create a Gizmo SDI that is based on a Gizmo Type, then use the Gizmo SDI. In this sense, you can think of a Gizmo SDI as an instance of a Gizmo that lets you point to a "base type" property tree, reference the node from which to inherit, and (if desired) override properties of that base type. This model is similar to the Workflow Task Step Definition model (see Introduction to Workflows).
To create a Gizmo SDI, go to the Gizmo List page (System Admin → Web Page Designer → Gizmos), then add a Gizmo by clicking "Add".
|
In the Gizmo Maintenance page, enter a "Gizmo Id" and Description for your new Gizmo. Choose the "Gizmo Type" to use (such as Bulletin Gizmo). Select the Node to inherit (such as SapphireCustom).
In the "Properties" tab, enter the properties you want to override.
|
Click "Save" and your new Gizmo is ready to add to the Layout or render from a URL. You can further customize your Gizmo by setting Gizmo core properties such as title. Here you can also specify the Notification information and Events for which to listen (this is covered in Gizmo Notifications below).
You can also edit the Gizmo Node directly by accessing the Property Tree for the Gizmo Type as shown below. Clicking the Gizmo Node loads the Gizmo Maintenance page.
|
These Gizmo Types are currently available for use:
If you want to create a new Gizmo Type, the process is similar to creating a new Element. Inherit the BaseGizmo public class and implement the available public methods (at a minimum the getHtml and getScript methods). You then register it in the "Gizmo Types" property definitions and set the "title" and "Image" in the Gizmo properties section of the new Gizmo Type property list.
Gizmos in Dashboards and the Sidebar |
Dashboards consist of one or more Gizmos. As such, a Dashboard is actually a Gizmo Group. See Dashboards for more information.
Gizmos can also be used separately or as Gizmo Groups in the Sidebar. See LabVantage User Interface → Sidebar for more information.
Gizmo Security |
With regard to Gizmo security, some Gizmos (such as the Menu Gizmo) allow Roles and Modules to be assigned to collection items, therefore restricting Menu item access. However, sometimes it is more important to actually prevent access to the Gizmo itself. Therefore, Gizmos have both SDI Module definition and SDI Role definition implemented on them. When you try to access a Gizmo, it validates that the current user has access through Roles and Modules. If not, the Gizmo will be unavailable (hidden from view). This is a good method of creating a global Sidebar and restricting items on the Sidebar by groups of Users.
Gizmo Notifications |
|
|
Overview |
Gizmos can be configured to automatically trigger a server-side Event in response to an HTTP request. This process is executed and managed by the LabVantage "Notification" framework. "Notifications" is a technology that allows Web browser clients to listen for Notifications of Events without using a polling mechanism. In general, this Notification technology is defined by the Servlet 3.0 Asynchronous Request Specification, which allows asynchronous response to an HTTP request.
|
This is managed server-side using a NotificationController servlet to manage the asynchronous requests, and a NotificationManager to manage the interaction between asynchronous client requests and Events generated server-side. Server-side events are typically automatically generated from internally generated Event Plans in the EventManager, although Notification Events can also be manually triggered by other means (such as when broadcasting an alert to all Users). The NotificationController and NotificationManager have no GUI. On the client-side, a Notification API handles Event subscription and requests from (or responses to) Notifications from the server-side NotificationController. The high-level diagram at the left shows the processes involved:
|
Example of Gizmo Notification |
In this example, we configure the Bulletin Gizmo (an instance of bulletingizmo) to send a Bulletin. Begin by making a copy of the Bulletin Gizmo, then editing the copy (below left). Next, click the ellipsis button in "Refresh on Events" (below right).
|
|
This opens the Notifications Events Editor, which shows the set of Events that will trigger the Gizmo to send the Bulletin. Note that this particular GUI for defining Events uses the same interface and mechanism as Event Plans. "Add" and "Edit" adds and modifies an Event, while "Delete" un-subscribes the Event so it will no longer trigger the Notification. Like Event Plans, the Conditions are synchronized with the Event Type.
|
The Bulletin Gizmo requires two Event Types to issue a Notification: SendBulletin and SetBulletinStatus. Configure SendBulletin for an existing User as shown below.
|
|
Configure SetBulletinStatus for an existing User as shown below.
|
|
You should have these defined as shown below.
|
Save the Gizmo. Logon as a different User, then send the Bulletin to the
User configured in the Gizmo. When the Bulletin is sent, the Notification
is issued and a counter appears
with the current Bulletin count (below left). Note that one Bulletin is queued
(below right).
|
|
If another Bulletin is sent to the same User, the count updates as shown below.
|
|
Notification timers can be configured using these properties if they are defined by the Gizmo:
| Property Name | Description |
| Refresh on Timer Every (sec) | This activates a timer to refresh the count every n seconds. In this example, the number of Bulletins would be refreshed. |
| Refresh on Events | Set of Events that will trigger the Gizmo. This is demonstrated in the example above. |
When a Gizmo receives a Notification, display characteristics can be updated using these properties if they are defined by the Gizmo:
| Property Name | Description |
| title | title text displayed on the Gizmo. |
| title Color | Color of the title text displayed on the Gizmo. |
| Counter Color | Color of the counter displayed on the Gizmo. |
| Flash on Update | Available if the Gizmo renders an image. Enabling this will flash the icon for about 5 seconds. |
Note that "title Color" and "Counter Color" are typically text strings. However, in some cases, they can be defined conditionally using a Groovy expression such as gizmo.count > 10 ? "Red" : "Green" .
|
Gizmos in Component Mode |
|
|
|
Component nodes can also be added to Gizmo Type Property Trees. To
operate in Component Mode:
|
When you add a Gizmo, the Component prefix is added (ABC_ in the example below).
|
When you edit the Gizmo Type, the "Add Component Mode" button lets you add a new Component node as shown below. The (Custom) node of the Component can then be modified.
|