Good to know your experience with Roo and the light weight approach.
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. It
is even better with Objectify if Jeff does it.
On Sun, 2010-10-31 at 02:30 -0700, Thomas Broyer 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;
> 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 email@example.com.
To unsubscribe from this group, send email to firstname.lastname@example.org.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.