On Mon, Nov 1, 2010 at 10:54 AM, Thomas Broyer <[email protected]> wrote:
> > > On 1 nov, 14:04, Jeff Schwartz <[email protected]> wrote: > > On Mon, Nov 1, 2010 at 8:22 AM, Thomas Broyer <[email protected]> > wrote: > > > > > Well, except that Guice for instance (and I believe JavaEE 6 too, as > > > it's based on JSR 330, lead by Bob Lee, creator of Guice) does not use > > > an XML file. > > > > Yes however I was specifically speaking to Spring DI. > > > > Isn't that somehow due to Spring insisting in "everything should be a > > > > > singleton" (and eagerly instantiating them)? > > > > I believe so, yes. > > So the issue is not DI (the pattern), but the Spring framework ;-) > I think I have already stated what my concerns are, Thomas, & I feel that you want me to say something that would confirm to you - in your mind at least - that I agree with. I don't and just to be clear I will offer my concerns one more time: 1) Reliance on Roo/STS if one wants to sync changes between Presenters & Views. 2) Roo adding Spring DI - one only has to look at the generated app context file to confirm this. And in the interest of clarity, my preference to the above is: 1) Rely on Java and refactoring to provide a similar ability to sync Presenters & Views even if it only flags errors indicating a discrepancy between an interface & its implementation. And no, I have nothing against Spring nor their DI implementation. Quite to the contrary in fact. As a company I think very highly of them. They have made numerous contributions to OS and I am grateful to them for that. As for their DI, I will use it when I feel it is the best solution. I don't want to use it because it is the only solution. > (and to answer my remark re. DI "that I'd encourage > *anyone* to follow", I wouldn't recommend using Spring for DI, unless > you want "configurability" through XML application contexts) > I wouldn't recommend to anyone to use any type of DI because it is the only option available. If it were the only option available I'd question my choice of development stack including framework and language. Fortunately, the situations where DI is the only answer are rare - I have never encountered one myself. I'd only recommend DI after carefully evaluating all the alternatives and concluding that DI is the best solution. I hope this lays to rest any questions you may have had. I think in the interest of the group this end the public track of this conversation. You can email me should you desire but like I said, I believe I have been very forthcoming and clear with my comments. Jeff > > > > My concerns aren't with MVP; from what I have read I think MVP is a very > > good design pattern & I am eager to incorporate it. My concerns are more > > aligned with the dependency on Roo & STS (which I use for Groovy and for > > Grails development & which I really like) to accomplish syncing Views & > > Presenters. I would have preferred a pure Java solution such as relying > on > > the compiler and code refactoring to generate binding code where needed. > > > > Jeff > > -- > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- Jeff -- 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.
