+1 on using Guice. It's a really lightweight way to get most of the benefits of DI.
On Tue, Mar 25, 2008 at 10:50 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Tue, Mar 25, 2008 at 10:43 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Tue, Mar 25, 2008 at 10:09 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > Might I pester some of you guys for feedback on this? > > > > Looks OK to me, maybe slightly more obscure than CrossServletState. I > > had to look up ServletContextListener, but it doesn't look like most > > people will need to touch that code. > > > Even fewer when Guice 2.0 is released, since this is already implemented > there. I'm sticking with what's in 1.0 for now though for compatibility's > sake. I wanted to make it so that you'd just have to implement a Guice > module (or modules) to modify the server. > > There isn't much change from the current state of affairs. > > Refactoring a few classes so they implement RemoteContentFetcher took > > around an hour this morning, and I think the code is cleaner for it. > > > > I still need the factory methods in CrossServletState. If anything > > they are getting more complex because of OAuth dependencies on a > > backend data store. I'm not sure how best to map this to Guice. > > Maybe inject a factory class? Would that defeat the purpose? If you > > can get a suitable replacement for GadgetSigner and > > makeSignedFetchRequestSigner working with Guice I'll probably have an > > easy merge. > > > A factory would be the way to go here, as far as I can tell. Someone with > more experience with Guice might know of some way to handle this without > boilerplate factory code. I should probably start reading guice-users > archives. > > -- > ~Kevin >
