On 11 July 2011 17:42, Franklin, Matthew B. <[email protected]> wrote: > On 5/19/11 6:49 PM, "Ross Gardler" <[email protected]> wrote: > >>On 19/05/2011 18:33, Franklin, Matthew B. wrote: >>> 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. >> >>I hate it (and love it) when that happens. >> >>I don't (current) develop for a living any more*. I've implemented >>something similar to this, but it is incomplete and since I've not been >>a real programmer for about 10 years I'm having to learn lots of cool >>new (at least to me) things. >> >>Now I won't get to commit my code :-( >> >>Of course, your code is better than mine and I've learned loads in my >>experiments. I'll merge the two together when I get chance. > > Hi Ross, do you think you will be able to tackle this before the end of > July release? If not, is there something that we can do to help? Maybe > commit your code to a branch and we can integrate it?
To be honest I can't remember the state I had it in. the primary technical problem is that the Java connector needed has not yet been released by Wookie and so a Rave release cannot include it. There is a vote underway over on Wookie right now for a release so that will be resolved soon. That leaves the other problem of my time to finish the work. I am well and truly swamped right now and I'm not going to finish it anytime soon. I know I was 80% there (meaning the hard 20% needs to be done). I think a branch would be overkill, but I can dump a patch into the issue tracker and if someone wants to finish it off then fine. Let me grab an hour somewhere to do this (I have loads of travelling this week so I may even get to finish it as I like to hack when travelling). Ross > > -Matt > >> >>Thanks Matt >> >>Ross >> >>* interestingly this will be changing for a few days a month in the >>coming months - I'm so excited to get some paid programming time back in >>my life >> >>> >>> -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? >>>> >>>> >>> >> > > -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
