On Thu, Mar 27, 2008 at 6:39 AM, Michael Mahemoff <[EMAIL PROTECTED]> wrote:
> It's encouraging to see DI incorporated into Shindig's architecture in > an explicit manner such as this. > > To accommodate the diverse needs of Shindig consumers, I'm hopeful > Shindig will, over time, become flexible and plugin-based. Adoption of > Guice would be a major step in that direction. > > Slightly OT, but I expect the Javascript code will also need a means for > consumers to switch between different implementations, in order to make > browser behaviour more flexible. It would probably work simply by > redefining certain variables, but would need a clean separation of > concerns in order to work. (Similar to JQuery's plugin architecture.) You can already drop in a custom implementation of any js feature. As long as the new code conforms to spec it's fine to replace it in your own deployment. In fact, it's actually a requirement for supporting opensocial-0.7 today. The other js (stuff in the javascript/) directory isn't nearly as robust, but I wouldn't really endorse using that code on a production site anyway unless you feel like doing a lot of work. Paul, Zhen, and Cassie have all been doing some work to make it more useful, but I feel that it should be scrapped and started from scratch to actually try to meet the needs of real sites. The original version was only created as a stopgap solution anticipating the creation of the gadget server. > > Kevin Brown wrote: > > Hi everyone, > > > > If you're not working with or interested in development of the Java > > implementation, you can ignore this. > > > > After discussing this on several separate occasions, I've decided to go > > ahead and give using Guice a shot. So far it's coming along pretty > nicely, > > though it does require a few small changes to some of the current > behavior > > (mostly cleanup of stuff that was known to be crufty and didn't really > get > > revisited in the last refactoring changes). For the most part, our code > was > > pretty DI friendly to start with, so the changes are minimal. Probably > the > > biggest change is that most configuration will be moving to an external > > properties file, and some new classes will need to be introduced to > handle > > various url generation pieces of CrossServletState. > > > > When I get closer to something complete, I'll be doing the usual JIRA / > > patch submission. > > > > If anyone has strong objections to Guice, feel free to speak up -- I've > > personally never used it myself, but I've heard good things from other > > people about it, and it seems to me to be a bit easier than Spring. > > > > For reference: > > > > http://code.google.com/p/google-guice/source/browse > > > > One minor annoyance -- I have had some trouble finding an up to date > maven > > repository, so I'm only using the initial 1.0 release that's available > on > > http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/ -- this > > doesn't include some of the servlet integration work, so I still had to > wire > > up pieces by hand. > > > > -- ~Kevin
