I don't want to open a big discussion on service locator vs dependency injection. I know you guys are trying to accomodate as many points of view as possible. I'll check if I can find something to help. The point was that there are situations when dependency injection prevents problems with systems that grow too fast in complexity. It all comes to people making assumptions that no longer hold, or just being plainly lazy.
Our problem was that people tended to group many services into the same locator, which created code dependencies throughout the whole system (couldn't compile or move a piece of code to another project without a big refactoring). The interesting is that Martin Fowler makes the same suggestion on his website... it was an assumption that code would never be reused in other projects so the dependency was not a big deal... oh well. Maybe the solution goes on the lines of using Spring to act as a factory for all components, and maybe have a default delegate (the normal Wicket classes) deal with it when Spring didn't know or didn't want to create a specific component. Does this make sense at all? []s Gus __________________________________________________________________________ UOL Fone: Fale com o Brasil e o Mundo com até 90% de economia. http://www.uol.com.br/fone ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
