On 5 May 2011, at 18:00, Franklin, Matthew B. wrote:
> On 5/4/11 6:25 PM, "Scott Wilson" <[email protected]> wrote:
>
>> On 4 May 2011, at 22:36, Franklin, Matthew B. wrote:
>>
>>> As we start to implement more of the OpenSocial constructs within the
>>> container, I think it is probably appropriate to begin discussing the
>>> impact of supporting multiple widget types on the model.
>>>
>>> Anyone have a strategy in mind?
>>
>> OpenSocial/Shindig requires a lot more plumbing than W3C Widgets/Wookie -
>> the only hook really needed for Wookie is to get the spec for rendering a
>> widget (title, height, width, iframe src) by calling the Wookie REST API
>> and for telling it who's looking at it (participant id/name/icon - same
>> as Wave). There are no data APIs or RPC hooks or anything like that
>> needed, though we probably would want to do something to support
>> inter-widget communication (extending Wookie to support the Shindig
>> pubsub feature might be the easiest solution there).
>
> The big question in my mind right now is constructs like User Prefs. In
> OpenSocial, UserPrefs are stored by the container via an RPC callback. I
> know W3C widgets have preferences, but I don't know where/how you
> envisioned them getting stored.
Currently Wookie stores them itself in its own data store, so there isn't any
particular need to do anything about them.
>
>>
>> I'm assuming that the basic idea is that the Rave Widget model class is
>> used to persist sufficient metadata about the widget (of whatever type)
>> so that it can be rendered by the layout engine at runtime for a
>> particular user? In which case there has to be some sort of service
>> method (WidgetService?) that each adapter for a widget type needs to
>> implement - did you have some ideas about what that should look like? I
>> guess I'm imagining something along the lines of:
>
> I think something like this might work well for inlined widgets. In
> OpenSocial, most widgets are not inline, and are initialized via the
> container on the client side.
Yes, I've just been exploring the code and seeing how the Shindig gadgets are
being rendered. The main difference for Wookie is needing to process the Widget
object with the current viewer and context before sending it to the view; e..g:
public String getHome(Model model) {
User user = userService.getAuthenticatedUser();
List<Page> pages = pageService.getAllPages(user.getUserId());
for (Page page: pages){
for (Region region: page.getRegions()){
for (RegionWidget regionWidget: region.getRegionWidgets()){
regionWidget.setWidget(widgetService.getWidget(user,
regionWidget.getId().toString(), regionWidget.getWidget()));
}
}
}
I've done this on my setup and it seems to work OK - I haven't committed
anything as the WidgetService connects to Wookie using the Wookie Connector
0.1.0-SNAPSHOT jar which isn't in a public repository. Plus it still looks a
bit hacky and clumsy :-)
For rendering we can use the same approach as for OpenSocial of getting the
client to render the content - I've tried it out with a script that builds an
iFrame tag and appends it to the element, and that seems fine.
The other requirement I can see is to hold height and width parameters in the
Widget object and push these into the view as these are obtained from the
metadata in W3C widgets rather than using callbacks to set the iframe size
dynamically.
S
>
> -Matt
>
>>
>> public URL renderWidget(User user, RegionWidget regionWidget){
>> }
>>
>> Or is it a bit more complex than that..?
>>
>> At the site level we also need some sort of palette or menu system for
>> adding widgets based on what's available in available containers. The
>> actual metadata is mostly quite similar - titles, authors, icons etc.
>> Wookie exposes metadata on all available widget in its REST API. Some
>> user stories for how we envisage users discovering and adding
>> widgets/gadgets to the workspace would be useful here.
>>
>>>
>>> -Matt
>>>
>>> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <[email protected]> wrote:
>>>
>>>> Implement User Prefs
>>>> --------------------
>>>>
>>>> Key: RAVE-27
>>>> URL: https://issues.apache.org/jira/browse/RAVE-27
>>>> Project: Rave
>>>> Issue Type: Technical task
>>>> Reporter: Matt Franklin
>>>>
>>>>
>>>> Implement persistence of user prefs, container services and RPC
>>>> callbacks
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> For more information on JIRA, see:
>>>> http://www.atlassian.com/software/jira
>>>
>>
>
