Both of these options are somewhat wasteful in the case where Caja's not included, unless I'm missing something. We could hack up something that filters out the enableCaja() method or any ___-including lines, but that seems a bit hacky to me.
Two other options: 1. Devise some kind of Caja API-export "spec," which is essentially a list of all properties and methods exported by the JS in question. 2. Derive something #1-like from JsDoc annotations and JS parsing. Either of these approaches would result in the Caja shim code being injected automatically. All options listed thus far still require that feature developers understand deeply what it means to tame APIs, which is unideal. Long term, I still like the "microkernel" approach described by the Caja team, wherein a core set of tamed APIs is provided to feature developers (and exported to outers), with feature code itself also cajoled. I still haven't wrapped my head around all the implications of that, optimization paths, etc. John On Tue, Jan 29, 2008 at 6:41 PM, Cassie <[EMAIL PROTECTED]> wrote: > 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 >
