Hey Jeff, Can you elaborate on what you mean by syncing views and presenters during development? Are you saying there's too much boilerplate such that Roo is the only practical alternative? If so, which boilerplate classes most concern you? We welcome discussion on ways to simplify. We definitely aim to make place mapping easier.
Thanks, /dmc On Mon, Nov 1, 2010 at 12:28 PM, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > Thanks, David, for clarifying this. > > If at any time it may have seemed that I was implying that there was was any > static dependency between Roo or Spring DI and GWT let me say that I know > there isn't. There is, though, an implied dynamic dependency between Roo, > Spring DI & MVP if one wants to synchronize their views and presenters > during development as per the Expenses example project. I say implied > because at this time it appears that the only available option to achieve > this is by using Roo but I am sure that there will be additional options > coming down the pike:). > > I am also very pleased to know that there will be improved tooling in the > Eclipse plugin. I spend more time using Eclipse than I do with my family lol > so it is reassuring to know that this will evolve. > > Again, thank you. > > Jeff > > On Mon, Nov 1, 2010 at 11:56 AM, David Chandler <drfibona...@google.com> > wrote: >> >> Hi Jeff, >> GWT 2.1 has no dependency on Roo. It is very much our intent that you >> should be able to create GWT apps with or without Roo. The latter offers >> some conveniences for certain types of apps like CRUD apps where you have, >> say, 40 entities, each with corresponding CRUD screens, and a view, >> presenter, RequestContext, DAO, etc. for each. In this example, the need for >> concrete classes per entity ultimately results from the fact that code >> generation (whether via GWT generator or Roo) is GWT's alternative to >> reflection. GWT 2.1 does not require much boilerplate and 2.1.1 will require >> even less. And yes, improved tooling in Google Plugin for Eclipse is >> definitely on radar. >> As far as DI is concerned, DI proper is not the cause of cold start >> latency on App Engine, but rather one particular scenario in which >> singletons are created eagerly at startup time. I wrote about this on my >> personal blog (http://turbomanage.wordpress.com) linked above. This should >> become much less of an issue shortly >> (per http://code.google.com/p/googleappengine/issues/detail?id=2456), as it >> appears the GAE team is close to releasing warmup requests, and reserved >> instances are on the roadmap. >> Best, >> /dmc >> >> On Mon, Nov 1, 2010 at 9:04 AM, Jeff Schwartz <jefftschwa...@gmail.com> >> wrote: >>> >>> >>> On Mon, Nov 1, 2010 at 8:22 AM, Thomas Broyer <t.bro...@gmail.com> 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. >>> >>> 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 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. >> >> >> >> -- >> David Chandler >> Developer Programs Engineer, Google Web Toolkit >> http://googlewebtoolkit.blogspot.com/ >> >> -- >> 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. > > > > -- > 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-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. > -- David Chandler Developer Programs Engineer, Google Web Toolkit http://googlewebtoolkit.blogspot.com/ -- 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.
