You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Overview and core concepts

viewer

widget instance

Creating a widget gallery

To make it easier for users to add widgets to parts of an application, you may want to provide users with a gallery of widgets.

Wookie provides the widgets interface for accessing metadata about currently installed widgets. There are two approaches that can be taken:

/wookie/widgets?all=true returns all the current widgets available. This is the method that most plugins will want to use.

/wookie/widgets with no parameters returns only the widgets set as defaults for the currently set widget services. This is mostly used for some advanced plugins for authoring tools.

Each method returns metadata including widget icons, titles, categories, and descriptions. This should be sufficient for creating a gallery user interface where a user can select a widget, and your application can use the identifier of the widget to create an instance, as covered in the next section.

Widget instance lifecycle

Requesting an instance

Whenever a user - the viewer - is to be shown a widget, your application needs to make sure you have a widget instance to show the user. To do this you should request a widget instance at /wookie/widgetinstances. The format of the request can be found in the REST API docuumentation, however the main points to bear in mind are how to construct the request parameters:

user_id: the user id is an identifier associated with the current viewer, and not the owner of the view. This doesn't need to be a "real" identifier, and can be a hashcode or other opaque value; you just need to be consistent.

shareddatakey: this value is used by Wookie to identify "sibling" widget instances that can share state information where appropriate (for example, in a chat widget). To do this an application needs to have a consistent process for generating this value. Typically this is an identifier already used in the application for identifying areas of pages; for example a combination of page identifier and a block or (native) widget identifier.

Note that subsequent requests for a widget instance will always return the same instance for the same given parameters - this means that if your application does not persist the instance data you can request it with each page view.

The response to a widget instance request contains a URL; typically you would use this information to construct an iframe tag with the correct height and width. Generally this is all that is needed to include a widget served by Wookie.

Adding Participants

Initial state information

Advanced functionality

Cloning widget instances

Stopping and resuming instances

  • No labels