On 16 May 2011, at 22:49, Franklin, Matthew B. wrote: > On 5/16/11 4:10 PM, "Ross Gardler" <[email protected]> wrote: > >> On 16/05/2011 20:56, Franklin, Matthew B. wrote: >>> On 5/16/11 3:11 PM, "Scott Wilson"<[email protected]> >>> wrote: >>> >>>> On 16 May 2011, at 19:56, Franklin, Matthew B. wrote: >>>> >>>>> I am still a little fuzzy on how this integration will work. The code >>>>> Scott has makes a call to a widget service that pulls back the >>>>> instance >>>>> of >>>>> the widget for the user. I am assuming we are then going to use this >>>>> instance to construct an iFrame URL that points back to Wookie for >>>>> rendering. >>>>> >>>>> What I was originally assuming was that the RegionWidget instance >>>>> would >>>>> contain everything needed to create the URL for the iFrame and we >>>>> wouldn't >>>>> need to replace it with a separate call to a widget service. >>>> >>>> Conceptually, there is a difference between what Wookie and Rave think >>>> of >>>> as a Widget "instance". >>>> >>>> In Wookie, a Widget Instance is both per-context (RegionWidget) AND >>>> per-viewer. So the RegionWidget references a single Rave Widget; Wookie >>>> has a collection of widget instances for each viewer of that Rave >>>> Widget. >>>> Hence its not really possible to pass everything needed, unless the >>>> Rave >>>> model was extended with a RegionViewerWidget (or somesuch). >>> >>> Just to clarify terminology (possible difference between OpenSocial and >>> W3C: >>> >>> An OWNER is the person who added the widget to the page and made any >>> customizations >>> >>> A VIEWER is the current person viewing the page and has read-only access >>> (Unless the current viewer is the owner) To widget properties >>> and preferences (not relevant until we have profiles) >>> >>> So given those terms, every viewer of the widget has their own instance? >> >> Not necessarily. >> >> Each widget instance has a unique combination of an APIKey and a >> SharedDataKey. It's possible that multiple users will have the same keys. > > OK. I looked over the API docs and what I propose is that we defer the > call to wookie to when we render the page. When we are outputting the > list of widgets to the page, there is some natural conversion to the > Javascript representation of the widget instance (as a string). If we had > a rendering facility that kept a handle on a map of widget converters by > widget type, we could call to it to build the string that we inject into > the page's script block as we are iterating over the RegionWidgets in a > Region. This way, we can have a W3C widget serializer that caches the > calls to /wookie/widgetinstances for a given user, SharedDataKey, etc and > we don't have to re-plumb the object model or service layer to support > what is in essence a rendering function. > > Usually not a fan of tags, but in this case, it might be worth it... > > Thoughts?
Sounds a plausible solution, but I think I'll understand it better in code :-) > > -Matt > > >> >> Ross >> >> >> >>> >>>> >>>>> >>>>> Ross, since you are taking on this piece, can you point me at some >>>>> docs >>>>> on >>>>> the connectors you are talking about? I think I am missing some >>>>> fundamental step in the Wookie rendering process :) >>>>> >>>>> -Matt >>>>> >>>>> On 5/11/11 4:39 PM, "Ross Gardler"<[email protected]> wrote: >>>>> >>>>>> On 11/05/2011 18:15, Scott Wilson wrote: >>>>>>> >>>>>>> On 11 May 2011, at 17:28, Ross Gardler wrote: >>>>>>> >>>>>>>> Sent from my mobile device (so please excuse typos) >>>>>>>> >>>>>>>> On 11 May 2011, at 13:58, Scott >>>>>>>> Wilson<[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 11 May 2011, at 13:23, Franklin, Matthew B. wrote: >>>>>>>>> >>>>>>>>>> I am assuming that this is a matter of creating a new rave-wookie >>>>>>>>>> project, >>>>>>>>>> similar to rave-shindig and adding the javascript to create the >>>>>>>>>> widget >>>>>>>>>> iFrame urls. Is there anything I am missing? >>>>>>>>> >>>>>>>>> For Wookie you need to request the Widget Instance corresponding >>>>>>>>> to >>>>>>>>> the current viewer before passing the Widget model to the view, >>>>>>>>> but >>>>>>>>> after that it should be about the same. >>>>>>>> >>>>>>>> Wookie provides connectors to make this all much easier. I have a >>>>>>>> use >>>>>>>> case for this feature. You can assume I'm going to take this issue >>>>>>>> sometime in the next couple of weeks (happy for someone to beat me >>>>>>>> off >>>>>>>> course). >>>>>>>> >>>>>>> >>>>>>> I've committed what I had, but with the actual "connector" bit >>>>>>> commented out in DefaultWidgetService - over to you, Ross! >>>>>> >>>>>> Thanks Scott. Hope to get to this "soon" >>>>>> >>>>>> Ross >>>>>> >>>>>>> >>>>>>>> Ross >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Matt >>>>>>>>>> >>>>>>>>>> On 5/10/11 10:30 AM, "Matt Franklin (JIRA)"<[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-30?page=com.atlassian. >>>>>>>>>>> ji >>>>>>>>>>> ra >>>>>>>>>>> .plug >>>>>>>>>>> in.system.issuetabpanels:all-tabpanel ] >>>>>>>>>>> >>>>>>>>>>> Matt Franklin updated RAVE-30: >>>>>>>>>>> ------------------------------ >>>>>>>>>>> >>>>>>>>>>> Fix Version/s: 0.1-INCUBATING >>>>>>>>>>> >>>>>>>>>>>> Render W3C widgets on Page in iFrames >>>>>>>>>>>> ------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> Key: RAVE-30 >>>>>>>>>>>> URL: >>>>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-30 >>>>>>>>>>>> Project: Rave >>>>>>>>>>>> Issue Type: Story >>>>>>>>>>>> Reporter: Matt Franklin >>>>>>>>>>>> Fix For: 0.1-INCUBATING >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Enable the rendering of W3C widgets inline on the page via >>>>>>>>>>>> iFrames >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> This message is automatically generated by JIRA. >>>>>>>>>>> For more information on JIRA, see: >>>>>>>>>>> http://www.atlassian.com/software/jira >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
