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