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? -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 >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >
