I have committed the implementation of this concept. There is now a rave.w3c package that contains a W3C RegionWidgetRender and a skeleton implementation of a WidgetService that can be completed to communicate with Wookie. The way this is implemented, the renderer will call the WidgetService to get the widget instance and then pass a javascript widget object to the w3c javascript. This can easily be changed to do whatever is best for Wookie rendered widgets.
In the future, the renderer can be extended to support inline widget rendering. -Matt On 5/17/11 8:19 AM, "Franklin, Matthew B." <[email protected]> wrote: >>>> >>>>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 :-) > >Ross was going to build the Wookie connectors. I will build the rendering >piece, so long as that does not conflict with what he is doing as part of >the Wookie connectors. Ross? > >
