I'd favor putting all of the caja enabling functionality into separate files for each feature. Something like this:
<feature> <name>rpc</name> <gadget> <script src="rpc.js"/> <script trigger="caja" src="rpc-taming.js"/> <-- Only one per library required, but you could separate them if you wanted to. </gadget> </feature> The "trigger" (name not important) attribute would cause the JsLibrary to only return the rpc-taming library when the "caja" feature is included (and the caja feature would be forced on any gadget that gets cajoled). I like this method because it is useful for things other than caja. rpc-taming.js might look like this: ___.allowCall(gadgets.rpc, ["call", "registerService"]); Any features that don't include a caja trigger would be forced to be cajoled along with the gadget itself -- this way features that haven't been properly tamed could still be used. This of course requires some minor server changes; specifically, support for triggered js libraries in JsFeatureFactory. This wouldn't be compatible with iframe + forced libs parameter, but I think that's OK because caja winds up inlining everything anyway. ~Kevin On Jan 29, 2008 7:26 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > 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 > > >
