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 :)
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.
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. 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.
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.
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.
Options are a developer's best friend IMO.
Have a great day.
Jeff
On Sun, Oct 31, 2010 at 12:44 PM, Thomas Broyer <t.broyer@gmail.com> wrote:
I think I already said it: I have zero experience with Roo.
On 31 oct, 15:26, Duong BaTien <duong.bat...@gmail.com> wrote:
> Hi:
>
> Good to know your experience with Roo and the light weight approach.
To really benefit from Guice (or more generally DI) on the server
> A best-practiced example of RequestFactory with GIN at GWT side and
> GUICE at server side may be what a mortal developer is looking for.
side, you'd first have to wait for GWT 2.1.1, as in 2.1.0
RequestFactory makes heavy use of static methods.
See http://code.google.com/p/google-web-toolkit/issues/detail?id=5482
(among others)
--
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-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment