To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/fc2nszYwqVYJ.--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/fc2nszYwqVYJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Did almost the same, but as a Maven plugin that scans the classpath for classes extending a few base classes.The only thing I regret: it's part of the build process, so proxies are recreated each time, and therefore cannot be tweaked; which means that if something needs to be tweaked, it has to be done at the code generator level.In retrospect, I'd rather have a "one shot" process: generate source code so you can tweak it; and when you change your domain model, either you update the proxies by hand, or you re-generate them. And because the sources would be checked in SVN/Git/whatever, you could easily merge/ignore the changes you made that the generator would have "cancelled". In other words, similar to what the GPE can do in RequestFactory/AppEngine projects.
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/k2On8kxH2H4J.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Many people using JPA/JDO or similar on the server-side already have DTOs and copy things from their entities to/from DTOs to bridge GWT-RPC and JPA/JDO.RequestFactory is not much different, except it does the "copying" part for you, and it adds better performance (serialization/deserialization on the client-side; partial graphs on server-to-client, and diffs on client-to-server), seamless upgrades (you're not required to update your clients when you change the server; and if you change contexts/proxies in "compatible" ways, you can live with "older clients" and up-to-date ones at the same time, no more "the app has been updated, please reload (and lose your work at the same time)"), and a few hooks (ServiceLayerDecorator).
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/E0NCjHtsx1sJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
> view implementations ... but honestly I'd rather have a smart view /
> presenter class that wires everything together. The processing is
> delegated to event bus or other handler that processes the business
> logic.
There's nothing stopping you doing this, you can use a UiBinder
template and backing class as a combined view/presenter. You will of
course lose the decoupling of views/presenters the MVP framework is
bringing to the table, and its advantages.
I havn't read the MVP docs in a while, but it should probably be
better explained that its just *one* way of doing GWT development, not
*the* way, and your free to use part of it, none of it, all of it,
depending on what you actually need. As a newcomer to GWT (and Java!)
I spent a lot of time on it when starting out, as it was the most
prominent documentation on how to do certain things (views and
'pages'/places in particular) for very little net gain. For simple
apps, using UiBinder and attaching the resulting widget to the page
manually lets you actually get to the meat of your application much
faster and with much much less complexity. You can always refactor to
MVP later.. (though that doesn't sound fun) anyway just my 2cents,
maybe with better tooling there would be fewer of these 'MVP is too
complex' threads.
And on tooling, and RequestFactory, the new annotation processor is
great, compile time validation really helps (I am manually writing my
proxies) but I was disappointed to see that the 'RPC tooling' is only
for Android Apps.
Are we expecting to see GPE provide Proxy/RequestContext generation in
the future for non-android apps?
I havn't read the MVP docs in a while, but it should probably be
better explained that its just *one* way of doing GWT development, not
*the* way, and your free to use part of it, none of it, all of it,
depending on what you actually need.
Are we expecting to see GPE provide Proxy/RequestContext generation in
the future for non-android apps?
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/oKfby3zLqUcJ.
--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
> And BTW, MVP is a design pattern, and there's no one single way of
> implementing it (the MVP articles in the GWT doc makes it kind of clear).
> And the fact that Activities and Places (which people sometimes erroneously
> call "MVP framework") are quite new makes it clear that it's not "the" way
> to build GWT apps: there must have been ways to do it before they're
> introduced!
>
Point taken, the docs do make it very clear its a pattern and one way
of implementing it, and that its best suited for large scale projects
and why. Though reading through the User Guide, you could be forgiven
for thinking 'This is the way I should go with my app!', especially if
you decide to use UiBinder, as the Activity/Places MVP article uses it
and is almost like a tutorial on building an app.
I guess its just because the other tutorial in the User Guide, the
Stock Watcher, doesn't use UiBinder, which is a very attractive
feature to anyone new to GWT. Would be nice to have a chapter/tutorial
on building a small/medium sized UiBinder based app that doesn't use
MVP.
http://code.google.com/p/mvp4g/
I have never used it, but it looks like a great alternative to reduce
the amount of work.
> --
> 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-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
--
Felipe Martim