Overview
The ActivityStream control is designed so that a small piece of JavaScript code will insert a Connections ActivityStream, in an iframe, into your html page. Since it calls the ActivityStream directly from your Connections server, any configurations which are available on your server will also be available using this control. There is an extra configuration option for using common extensions, for enabling commenting on, saving and deleting posts and for refreshing the stream, but otherwise it will use the standard configuration options.
Usage
The ActivityStreamWrapper control takes the following as arguments, within a single object:
feedUrl: A relative or absolute url which points to a feed. Relative being relative to the opensocial context root on the server. e.g. "/basic/rest/activitystreams/@public/@all/@all?rollup=true",
activityStreamNode: The id of the html node (in the template) that you want to attach the stream to. If not present the ActivityStream won't attempt to render. Defaults to "activityStream".
shareBoxNode: The id of the html node (in the template) that you want to attach the share box to. If not present the ShareBoxNode won't attempt to render. Defaults to "inputForm".
sideNavNode: The id of the html node (in the template) that you want to attach the side navigation bar to. If not present the side nav won't attempt to render. Defaults to "sideNav".
extensions: Shorthand for some extensions. These map to real connection extensions and this is part of the wrapper so that you can use extensions without a full config object, and without knowing the names of the extensions, which are long package names. Possible values are true or false and the list is below.
{
commenting: true,
saving: true,
refreshButton: true,
deleteButton: true
}
config: An ActivityStream config object. I described it in the doc so people can get up and running but a full description is probably better gotten from the ActivityStream documentation.
endpoint: The name of the endpoint to use.
Either a feedUrl or a config object can be specified. If both are present, the config will be ignored.
Basic Example
The simplest way to instantiate the ActivityStreamWrapper is to provide it with a feedUrl and the ids of the divs it should attach to.
Let's look at an example:
require(["sbt/dom", "sbt/config", "sbt/connections/controls/astream/ActivityStreamWrapper"], function(dom, config, ActivityStreamWrapper) {
config.Properties["loginUi"] = "popup";
var activityStreamWrapper = new ActivityStreamWrapper({
feedUrl: "/basic/rest/activitystreams/@public/@all/@all?rollup=true",
activityStreamNode: "activityStream",
shareBoxNode : "inputForm",
sideNavNode : "sideNav",
extensions: {
commenting: true,
saving: true,
refreshButton: true,
deleteButton: true
}
});
dom.byId("activityStreamDiv").appendChild(activityStreamWrapper.domNode);
activityStreamWrapper.startup();
});
This is how we instantiate the ActivityStream. The things to notice here are:
- Required Classes
We require 3 classes to make this work. The first, sbt/dom, is the sdk's library-independent dom manipulation module. sbt/config is for general configuration (we set the loginUi to be a popup, though this is default in the ActivityStream control anyway). The last one is the ActivityStreamWrapper module itself.
- Simple configuration
We instantiate the Wrapper using the feedUrl argument, which is a standard part of the Connections ActivityStream config object. This url can be absolute or relative. A relative url is relative to the opensocial context root on your server. This context root can be modified by admins however, so it is recommended that you use a relative url to reduce your maintenance overhead. The extensions object is not part of standard ActivityStream, however they map to the extensions array which can be passed into an ActivityStream asConfig object (See the section on configuring the ActivityStreamWrapper).
- Authentication
You will also notice the url begins with /basic. This is how we can tell which authentication method to use. The three authentication methods are: oauth/, basic/, anonymous/; OAuth authentication, Basic authentication and no authentication, respectively. You will need to use some form of authentication to access non public streams.
- Widget Inclusion
There are three widgets which can be used here, and thus three XXXNodes to specify. Any which are left out will not be displayed, so if you don't want the sideNav or the ShareBox, or even the activity stream, leave them out. The values of the XXXNodes are the ids of the div in the iframe template.
- Instantiation
In the last two lines, now that we have set up the wrapper we get the id of the div we want to attach the iframe to and append the wrapper to it. We must then call the startup() method to initialise it.
Configuring the ActivityStreamWrapper
Since the ActivityStreamWrapper is configured using the exact same configuration object as the Connection Activity Stream, it is just as customisable.
Again, let's look at an example:
require(["sbt/dom", "sbt/config", "sbt/connections/controls/astream/ActivityStreamWrapper"], function(dom, config, ActivityStreamWrapper) {
config.Properties["loginUi"] = "popup";
var asConfig = {
urlTemplate : "/connections/opensocial/rest/activitystreams/@me/@all/${appId}",
defaultUrlTemplateValues : {
userId : "@me",
groupId : "@all",
appId : "@all",
rollup : "true"
},
views : {
simpleView : {
filters : {
label : "Show:",
options : {
all : {
params : {
appId : "@all",
},
label : "All Types"
},
blogs : {
params : {
appId : "blogs",
},
label : "Blogs"
},
profiles : {
params : {
appId : "profiles"
},
label : "Profiles"
}
}
}
}
}
};
var activityStreamWrapper = new ActivityStreamWrapper({
config : asConfig,
activityStreamNode: "activityStream",
shareBoxNode : "inputForm",
sideNavNode : "sideNav"
});
dom.byId("activityStreamDiv").appendChild(activityStreamWrapper.domNode);
activityStreamWrapper.startup();
});
As you can see this is the same as the above example, except it specifies a basic configuration object instead of a feedUrl.
The Config Object
While ActivityStream has its own documentation, the configuration object is described here for convenience.
The structure of a feed url is "/connections/opensocial/rest/activitystreams/${userId}/${groupId}/${appId}". To change the url to point to different feeds you need only change the userId, groupId and appId. The configuration object exists to let you specify different feeds using views and filters, and these views and filters work by changing the ids of the feedUrl.
For example in the configuration above, our url template is "connections/opensocial/rest/activitystreams/@me/@all/${appId}"
. This means we will only want to change the appId part of the url in our views and filters.
We specify a 'views' object, and in here we create one simple view. Each view contains a filter, so inside the filters object we put a label and the options for filtering the feed.
When we switch to the "all" filter, our appId will change to @all, making the url the feed points to "connections/opensocial/rest/activitystreams/@me/@all/@all", and similarly when we switch to the blogs filter our url will become "connections/opensocial/rest/activitystreams/@me/@all/blogs". You could also swap the entire url by specifying url instead of params. e.g. instead of
params:{
appId : "profiles"
}
use
url : "/connections/opensocial/rest/activitystreams/@me/@all/profiles"
These are the basics of creating a configuration for your stream. There are other samples in the toolkit, including one which uses the Connections configuration and one which has multiple views and filters, so check those out for inspiration.
Parent topic: UI components