Thomas, It is the 'I' in DI that I reflected on: Injection takes cpu cycles and on App Engine server cpu cycles are severely restricted by numerous quotas; the penalty for exceeding them cause cascading conditions of failure. If you aren't familiar with App Engine hosting and its quotas perhaps you should read up on it.
As for ROO not generating server side DI as part of its tooling in STS when used with GWT I will have to check that out for myself; I believe I had read that it generates a server side application context configuration file and if that is the case then I'd like to know why it would do that if DI wasn't employed on the server. If that is the case then DI would certainly cause heightened latency causing an increase in 500 errors on App Engine virtual server cold starts. As for DI being a best practice (that you'd encourage *anyone* to follow) well that is your opinion that is not shared by everyone. I encourage a more conservative approach to any engineering problem - use the right set of tools at the right time. As for Huh!?! That is something best saved for your friends on Facebook. This is a technical news group where such antics of conversation are not appreciated regardless of difference of opinion. Jeff On Sun, Oct 31, 2010 at 5:30 AM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > On 30 oct, 23:15, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > > Excellent! Thank you for the information. I still however have to wait > until > > support for DAOs & embeded objects is implemented in the MVP framework (I > am > > using Objectify for my ORM as well ass a DAO) before I can cut over. > > > > I am also concerned about the apparent reliance on Roo to generate the > > boilerplate code. It appears that Google is very much behind this combo. > > We've been prototyping with RequestFactory for months and haven't ever > used Roo (our backend is Morphia+MongoDB, not too far from Objectify) > > > It > > isn't that I have anything against Roo, DI or generated code for that > matter > > but I would have preferred a leaner solution. > > AFAIK, Roo is only a dev tool to generate and maintain boilerplate > code. There's nothing related to Roo in the generated code (have a > look at the Expenses sample, the domain objects and all Scaffold* > classes are those generated by Roo). > > RequestFactory goes against DRY as you have interfaces extending > EntityProxy on the client-side, and "whatever" on the server-side; but > it's lighter weight than e.g. GWT-RPC at runtime: lighter payload > going on the wire (in most cases, and particularly on "upload"), and > much much lighter and faster on the client-side as parsing the payload > is just a matter of JSON.parse() > > > Applications targeting App > > Engine already experience enough latency on start-up and I am afraid that > DI > > will just make matters worse; > > Huh!?! > > Could you explain to me how DI slows things down? It's merely about > moving the place where you "new" objects, I don't see where there'd be > overhead re. start-up time. > Noteworthy: Roo generates GWT apps that use GIN for DI on the client > side, but there's no DI at all on the server-side. And DI is > absolutely not a requirement; only a best practice (that I'd encourage > *anyone* to follow) > > > -- > 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<google-web-toolkit%2bunsubscr...@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.
