rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: [jira] [Created] (RAVE-27) Implement User Prefs
Date Thu, 05 May 2011 18:45:37 GMT

On 5 May 2011, at 18:00, Franklin, Matthew B. wrote:

> On 5/4/11 6:25 PM, "Scott Wilson" <scott.bradley.wilson@gmail.com> 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)" <jira@apache.org> 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
>>> 
>> 
> 


Mime
View raw message