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