On 27 Jul 2011, at 11:42, Ross Gardler wrote:
> On 27 July 2011 08:49, Michael Aram <[email protected]> wrote:
>> Hello,
>>
>> wouldn't it make sense to use the "shared_data_key" for this kind of
>> feature? Assuming, that the container already chose a sensible
>> shared_data_key during instantiation (e.g. the current page, or the current
>> course) for the widget instances of interest, then a Wookie REST API
>> function like
>>
>> GET {wookie}/widgetinstances {params: api_key, shared_data_key}
>
> It's a good idea, but it won't give the information required. This
> would tell us all instances that have been created with that key. It
> won't tell us which instances are currently displayed on the container
> page. There is no way for the Wookie server to know what a container
> is currently displaying and I doubt it would be a good idea for it to
> have such a tight integration.
If you are using a vhost configuration where your platform and wookie use the
same origin, a simple method is to use the page itself to gather the
information. Each widget iframe contains the widget metadata object in its top
level browsing context, so you can iterate over all the child iframes in the
dom and get hold of widget.identifier; e.g.:
var widgets = [];
var iframes = document.getElementsByTagName("iframe")
for (var i=0; i<iframes.length;i++){
widgets.push(iframes[i].contentWindow.widget.id);
}
