So I have a bunch of caja code for gadgets that looks like this: outers.gadgets = gadgets; ___.allowRead(gadgets, 'views'); ___.allowCall(gadgets.views, 'requestNavigateTo'); ___.allowCall(gadgets.views, 'getCurrentView'); ___.allowCall(gadgets.views, 'getSupportedViews'); ___.allowCall(gadgets.views, 'getParams');
etc etc etc Plus a bunch of general code which modifies that "outers" var above to emitHtml, sanitize it and what not. You can see the container.js file for an idea of what I mean (line 422 on): http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/container.js We have several options for including the code in the gadgets js files so that caja is supported. 1. Throw all of the caja allow calls together in one method, probably in core.js. Call this method (opensocial's version is enableCaja) when someone wants caja enabled. (note: both cajoled and non-cajoled gadgets still work with this js code) - pros: caja doesn't have to be enabled at all if someone just doesn't call the magic method. it is also nicely encapsulated and the caja feature can be loaded whenever. also, a non shindig container can copy and paste this all in one place code easily. - cons: your methods are not next to the string versions. this is some what mitigated by the fact that we have a very clearly defined spec. 2. Put the parts that can be separated into each of the corresponding .js files. (This would require the core feature to depend on the caja feature as well.) - pros: all of the string versions of the methods are right next to their code counterparts - cons: you've got caja scattered everywhere! if someone doesn't want caja in their shindig for some reason they will have a lot of ripping out to do. Any opinions or other options? - Cassie
