shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Simpler taming of opensocial, gadgets and related apis
Date Tue, 20 Oct 2009 21:53:57 GMT
Aside from the rather minor comments below, my primary concern is that
this adds bulk to every gadget render, not just those that are cajoled.

This said, I agree it's the right move to include tamings with features
themselves. It appears that tamings for gadget and container context are
equivalent - if so, a new RenderingContext.CAJA might be in order:
   <script src="..."/>

Or we could try to genericize this by adding extensible syntax:
   <script src="..."/'>
...the content of which could be read by a Rewriter
(CajaContentRewriter) and injected as needed.

...or something similar. Thoughts?
File features/src/main/javascript/features/caja/taming.js (right):
Line 105: var tamings___ = tamings___ || [];
Not that it's a big deal in this case, but maybe it should be. This is
one of a few use cases I've seen arise that call for a clearer
representation of the feature dependency tree.
Line 115: ___.grantFunc(imports.outers.console, 'log');
nit: I wonder if this is necessary, vs. just encouraging people to use
File features/src/main/javascript/features/flash/taming.js (right):
Line 1: /*
Missing a corresponding feature.xml update for flash.
Line 36: var O = ifr.contentWindow.Object;
possible mini-optimization: pull A and O above var cleanse to avoid
having to recreate the frame.
Line 59: var JsonRpcRequestItem = function(rpc, opt_processData) {
nit: spacing 2 to the left.

View raw message