----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1199/#review1203 -----------------------------------------------------------
trunk/features/src/main/javascript/features/exportjs/exportjs.js <https://reviews.apache.org/r/1199/#comment2669> Done - johnfargo On 2011-07-26 21:26:55, johnfargo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/1199/ > ----------------------------------------------------------- > > (Updated 2011-07-26 21:26:55) > > > Review request for shindig and Michael Hermanto. > > > Summary > ------- > > When exportJs(...) is used in deferred-binding mode, its namespaces usually > don't already exist. Example for fictional API foo.bar.baz: > > exportJs("foo.bar", [foo,foo.bar], {baz:"baz"}, 1); > > This is problematic because the namespaced vars, when interpreted by the > browser, do not yet exist and thus throw an error. To get around this with > the root namespace, we prepended "window.", but this simply supports > one-layer NS. > > This CL changes the pattern to: > exportJs("foo.bar", { foo: "foo", bar: "bar" }, { baz: "baz" }, 1); > > The export method uses the second argument's symbol map to generate/upsert > namespaces based on the possibly-obfuscated symbol expansions. Support in the > JS is provided for both new- and old-style (array and Object) for a time to > prevent version skew issues. The Array-based approach will be removed later. > > > Diffs > ----- > > trunk/features/src/main/javascript/features/exportjs/exportjs.js 1145744 > > trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/js/ExportJsProcessor.java > 1146884 > > trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/js/ExportJsProcessorTest.java > 1146884 > > Diff: https://reviews.apache.org/r/1199/diff > > > Testing > ------- > > > Thanks, > > johnfargo > >
