I'm just now starting to get into the Ext.Direct stuff and am pretty excited about it so far. Took 16 db calls that were getting 'blocked' at the browser level and got them all in 1 call. Pretty awesome! I was going to package it all up for deployment but ran into the seemingly common issue of the order of data loading being an issue when doing this. Specifically my API is being generated as normal but since I have all the stores/models being loaded either before the ext.direct.manager can load the API (when compiling the jsb file and including the addProvider command in the application definition) or it just won't work since ext.direct.manager isn't loaded yet after adding it to the index.html file like the traditional methods.
So my question is, has anybody found a good solution to this problem that doesn't involve reworking stores/models but still gets everything in the jsb file? I'm thinking of making a smaller jsb file specifically for the direct.manager data, loading it immediately after the ext.js file and then doing the traditional addProvider call. Make sense? Anybody else gotten anything good to work?
Hopefully this makes sense. Writing this out on the iPad is brutal.
Well, if anybody else runs into the issue, it DOES work how I described. I created a mini app (ok one line that requires Ext.direct.*) to load the Direct files, then I created a JSB, compiled it, and added that immediately after my ext.js load in index.html. Immediately after THAT I execute my addProvider command and everything worked like a charm. So... a mini-hack that works better than overriding stores and other such things in my opinion. If anybody has any other methods that are more efficient I am more than willing to switch my way of doing it!
Yes this is a common problem. I tried what you suggested some time ago; it led to all kinds of headaches and didn't solve the race condition problem anyway. Just wait till you have deployed it in production, and you'll see that it's perfectly possible for the application script to load (from cache) much faster than server could respond with API declaration. Kaboom.
Sure you can try to jump through hoops to shift the race condition from API vs application to some other form but you can't eliminate it completely. Modifying your Stores, Forms, etc to declare API in constructor is not that hard and is much better from long term maintenance point of view. See my answer to a similar thread.