Caja fans,

This is description of some of the results of the following change --

  http://code.google.com/p/google-caja/source/detail?r=3846

Basically, what that change does is make it so that Caja always cajoles in
Valija mode by default. (We justify this by noting that Valija is our
simulation of "regular" JavaScript, so it makes sense as a default.)

In order to select Cajita mode, a programmer must opt in, using the
directive:

  "use cajita";

at the top of their source file or:

  function foo() {
    "use cajita";
  }

at the top of their function.

It is now not possible to cajole HTML as Cajita. This was never really truly
supported beyond some test cases internal to the Caja codebase, because
connecting <script>s together in HTML requires the semantics of Valija.
However, individual <script>s (and functions) in HTML can still opt into
Cajita as above; specifically, <script>s can do:

  <script>
    "use cajita";
    /* code here */
  </script>

One outcome is that the RESTful cajoling service no longer accepts a flag
specifying Cajita vs. Valija mode. This means that one just feeds content to
the cajoling service, and it returns the appropriate compilation. This is a
Good Thing [TM] because, otherwise, every API that called the cajoler (such
as, say, the module system) would have to have a "Cajita/Valija" flag or
make unwarranted assumptions.

Part of this change is that we now name all cajoled files "*.out.js"
regardless of whether they are produced from Cajita or Valija. We recommend
similar behavior on the part of any other cajoling systems our clients might
construct, since it simplifies the manner of finding a cajoled file given
the name of the un-cajoled file: it is not necessary to know whether the
original was Cajita or Valija.

Mike Stay has promised to update his "Caja hosting modules" page with
concrete examples that should help show the new (and easier) way of doing
things.

Cheers,

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA

Reply via email to