How should gadgets js handle caja integration?

[Cassie <do...@apache.org>]

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

Re: How should gadgets js handle caja integration?

[Kevin Brown <et...@google.com>]

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 <fa...@google.com> 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 <do...@apache.org> 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
> >
>

Re: How should gadgets js handle caja integration?

[John Hjelmstad <fa...@google.com>]

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 <do...@apache.org> 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
>