On 31 oct, 18:57, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > Hi Thomas, > > No hard feelings, I assure you, and I think your English is very good so > please don't feel insecure. I apologize if I came off with an attitude; I > didn't mean to, but it was early in the morning and I didn't have my 1st cup > of coffee :)
OK, no problem. > Roo is a Spring Source technology as is STS & Spring DI. Spring DI uses an > application context XML file placed in the war which upon application start > up is read. If its contents include declarative class nodes then those > classes are instantiated and any additional parameters may also be assigned > to their properties to bring them into a usable state. Within the > application's code are DI attribute declarations that are used by Spring DI > for injecting the objects into the application. Almost all of the Java based > DI technologies work in a similar fashion. 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. > The benefits of using DI can vary. It is handy when you want to mock classes > for testing, for instance. It is also handy for providing the ability to > switch among the numerous implementations of common APIs. These are very > worthy capabilities and in the right situations are handy to have. I > personally use Spring DI with Wicket and Hibernate. They work together very > well. > > But with the positive also comes the negative just like with most things in > life. For instance, many developers view maintaining an application's > context file as burdensome and often complicated. In truth, at least IMO, > this is best served by tooling provided in an IDE which understands the XML > schemas and which can provide some code completion as well as intelligent > feedback. That's why Guice does not use XML but only plain old Java with annotations. It's in some situations not as flexible as Spring though: http://code.google.com/p/google-guice/issues/detail?id=167 (for instance) See also: http://code.google.com/p/google-guice/wiki/SpringComparison But Spring can also be used without an XML configuration: http://blog.springsource.com/2009/12/22/configuration-simplifications-in-spring-3-0/ (it's much like "DI by hand") > STS, Springs' added value release of Eclipse, does just that but > not everyone is using STS. On App Engine, one has 30 seconds to complete an > HTML request. While that may seem like a lot of time, it isn't when you > consider that on App Engine the time allocated to starting up a new virtual > server to service the request is also included in that 20 second quota. > Exceed that quota and your request fails with a 500 error. As DI requires > additional cpu cycles to do its magic, it may cause an application to exceed > the 30 second quota and fail at start up which I am sure you would agree is > something to be avoided. Isn't that somehow due to Spring insisting in "everything should be a singleton" (and eagerly instantiating them)? > So I am not opposed to DI at all, I just prefer to have the option of using > it or not using it such as on App Engine. So I assure you RequestFactory does not imply DI; much the contrary actually (in 2.1.0) ;-) > In regard to GWT v2.1 MVP, it seems apparent to me that Google is > championing Roo as their choice for developers to use when integrating MVP > into their GWT applications. From the little I really know about it, Roo is > able to generate a lot of the boilerplate code needed to keep the views, > models and presenters in sync. This is fine but I would have preferred if > Google had also provided options such as extending the code refactoring > ability in Eclipse to provide this support. I imagine this wouldn't be a > trivial effort but what is when it comes to developing applications? As an > example of what I mean, currently when adding a RemoteService using Eclipse > all the bindings between the service interface, the service async interface > and the service implementation are automatically generated. If I add a > method to the service interface and forget to add its implementation it is > flagged as an error. This type of 'built in' support is very intuitive as > well as productive since the developer is already familiar with their IDE. I > can imagine this can also be done with MVP in Eclipse and would eliminate > the need for Roo altogether. I don't know exactly what Roo generates, but there are two parts: - validation: EntityProxy re. their @ProxyFor counterpart, and RequestContext re. their @Service counterpart, and Editor<?> re. the edited object: yes having validation right in the IDE would be great, but it can only be done one way (an EntityProxy/RequestContext method doesn't match any method on the @ProxyFor/@Service class, Editor trying to edit a property that doesn't exist on the object; or type mismatch; but you won't want e.g. the EntityProxy being flagged because it doesn't map a method of the @ProxyFor object, as that could very well be by-design in your code). Apart from type mismatch I can't see a very useful "quick fix" apart from removing the method/property. - maintainance: AFAICT, Roo only maintains in sync the "scaffold" activities and views it has itself generated; that's the job of Roo really (from what I know about it, including with other kind of projects, e.g. Spring Surf), and I'm not sure I'd want it in my IDE, if it'd be possible at all (I mean, unless I "opt-in", as with STS, which AFAIK automates the launch of Roo to sync things, through AspectJ). > Options are a developer's best friend IMO. I cannot agree more! (and I think the GWT team agree too, their partnership with VMWare is about choice: http://code.google.com/cloudportability/ ) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
