First of all, I applaud your efforts and you've definitely done a nice job of documenting your findings. I will offer a few comments on the solution, though.
I like that you've taken the idea of my PresenterProxy (http:// groups.google.com/group/google-web-toolkit/browse_thread/thread/ 6ec343860253c621/20ab002804a6ee6e) and expanded it to support most any class imaginable. However, a side effect of this solution is that dependent classes (your ButtonPanel, in this example) must now be updated to rely on the *Shim class instead of the original class used before the shim. One of the tenets of dependency injection is that you should be injecting dependencies according to interface, not implementation (see Martin Fowler's explanation: http://www.martinfowler.com/articles/injection.html#InterfaceInjection). So your dependent classes shouldn't have to change when your implementation changes, nor should they care what type of implementation they receive. So in that regard, while using the shim may provide a nice way to abstract some boilerplate, it does break your existing API contracts and it requires that you define new *Shim contracts that are likely to duplicate existing API contracts. If the underlying implementation in the shim is to be created and delegated to asynchronously, then it is true that each shimmed method must return void (similar to the RPC async interfaces), and that imposes some limitation on what we can readily abstract. But perhaps you are on to something with the use of deferred binding. However, maybe what we should be looking at doing with the deferred binding is utilizing a generator that can (at compile time) generate a unique subclass of the original class capable of performing the asynchronous grunt work automatically. Perhaps if I have some time I can toy with that idea... On Feb 17, 2:29 am, Joe Cheng <[email protected]> wrote: > If you've tried introducing multiple split points into your app, you might > have found yourself cutting and pasting a lot. You might have tried getting > rid of that cutting and pasting by introducing a common delay-loading > abstraction. You probably discovered that this results in all the different > split points you wanted, being mashed into one big one. So you went back to > cutting and pasting. > > At least that's the meandering path I (and several others on this list) > took, before I discovered that you could use deferred binding to do all the > dirty work for you, leaving your source nice and clean. I've tried to wrap > up my efforts into a reusable package, which I've blogged about here: > > http://jcheng.wordpress.com/2010/02/16/elegant-code-splitting-with-gwt/ > > There is a steeper learning curve on this than I'd like, hence the length of > the post. If you have any feedback on the approach, the code, or the > writeup, I'm all ears... > > Thanks- > Joe Cheng -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
