Thanks Ihab, Mark. Very clear answers. I have some additional questions/thoughts which I'll post under some new subject lines.
I had mentioned the OpenAjax Alliance which is here: http://www.openajax.org/member/wiki/Main_Page. They have a long member list, including Google. They announced recently their OpenAjax Hub2.0 Specification which is here: http://www.openajax.org/member/wiki/OpenAjax_Hub_2.0_Specification and may be worth your time to review. They are also nearing their OpenAjax Metadata 1.0 Specification (http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification) which has some overlap with opensocial. Their pub/sub framework doesn't subsume or integrate DOM events including 'message', and it doesn't have serverside routing like postMessage. They have code here: http://sourceforge.net/projects/openajaxallianc/. Thanks Kam On Sep 12, 6:34 pm, [email protected] wrote: > On Sat, Sep 12, 2009 at 1:16 PM, kkasravi <[email protected]> wrote: > > Interesting, so the includeScript assumes the resource exists or > > that it must be fetched? > > Yes, more or less. The name passed to includeScript eventually gets > passed on to your loader, which is provided by the containing page in > un-cajoled (= privileged) code. The cajoled code may get the name: > > "foo/bar" > > and the loader might translate that to a fetch of: > > "http://example.com/software/foo/bar.vo.js" > > or perhaps even: > > "http://caja.appsopt.com/cajole?url=http://example.com/software/foo/ba..." > > > From the usage it looks like the call is synchronous. > > Yes. You can only call includeScript with a string literal (= known at > compile time), at which point the framework can guarantee that the > module you ask for will be available synchronously. If you want to > includeScript with a dynamically computed identifier, you do: > > var identifier = /* something */; > Q.when(includeScript.async(identifier), function() { > // This is an async callback > // Here, you react to the loading of the script > }); > > > Is there an equivalent includeModule? > > This is it. :) includeScript includes a Valija module into the current > Valija context. We called it includeScript because it mimics the > semantics of the <script src="..."> tag -- in that the code that is > loaded shares the same global variables as the code that loaded it. > > > Somewhat related to modules and valija sandboxes: > > How do events work? Assuming the existence of custom events > > and a subscriber has registered for an event where the producer > > is within a different valija sandbox? > > We don't have a specialized event system. > > Domita provides a tamed setTimeout() method that behaves pretty much > just like the real one (if it isn't, tell us: it might be a bug). > > Between any two pieces of code -- Valija, Cajita or otherwise, whether > or not in the same Valija sandbox -- events just cause code to be > executed. Nothing special. > > > Also what happens if the > > event references module instances that the producer has included > > prior to firing the event but the subsciber hasn't? > > Again, we don't do any special thing about this. You have to check > that you have what you need when you react to an event. The module > loading is just another asynchronous invocation like any other. > > We do provide the promise API (the 'Q' object) that simplifies things > somewhat. So if I were to do: > > var moduleVow = includeScript.async(identifier); > > the variable 'moduleVow' now contains a "promise" for the loading of > the module. I demonstrated this in shortcut form above, without > assigning the promise to a variable. However, here, if you have > several things that need to wait, you can do in any number of places: > > // Somwhere ... > Q.when(moduleVow, function() { /* do something */ }); > > // And somewhere else entirely ... > Q.when(moduleVow, function() { /* do something else entirely */ }); > > Cheers, > > Ihab > > -- > Ihab A.B. Awad, Palo Alto, CA
