concerns on 2.1 MVP approach

[marius.andreiana]

Hi GWT developers,

There are some concerns on 2.1 MVP approach, which have been raised
here
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/44cc77811080a288/f53f9d29ebb9257d?lnk=gst&q=mvp#f53f9d29ebb9257d
and here
http://groups.google.com/group/gwt-platform/browse_thread/thread/862cab91ccb28d40

To summarize, here are some quotes:
* It's extremely fast to build an initial scaffold (CRUD for all
entities), but I'm not sure how easy it is to customize it for real
world usage
* When skimming the generated sources I saw A LOT of artifacts, which
I don't feel comfortable with because it means that although
"officially" my code is not coupled with Roo, if I were to drop it I
would have to manage all these generated artifacts myself.
* This expenses example is a nightmare to follow. The bindings/
wiring of all the pieces both client and server is nuts.
* In M2, things have been cleaned up a bit

I'm just trying to make sure the final MVP implementation will be
usable without Roo and without automatic code generation, and will be
at least as easy to use and understand as http://code.google.com/p/gwt-platform/
. Otherwise, should it be left as a separate project rather than
default GWT approach?
What do others, more knowledgeable persons than me, think?

[PhilBeaudoin]

I found the following overview interesting too:
http://www.over-look.com/site/index.php/documentation/techblog/item/gwt-2-1-tutorial-1-mvp-the-model
The DTO model described there seems a little involved. If I understand
correctly, there is a client-side and server-side version of the DTO
for each of your model objects. The role of the latter seems to be to
support JDO/JPA. I have recently moved away from JDO and am a very
happy user of Objectify. As a consequence, both my server (objectify)
and my client (gwt-platform) are type-agnostic when it comes to model
objets. So another question I have:
* Does using GWT 2.1 MVP model forces me to annotate all my domain
objects with @DataTransferObject and have them inherit from Record?

Cheers,

Philippe

On Jul 9, 2:31 am, "marius.andreiana" <marius.andrei...@gmail.com>
wrote:

> Hi GWT developers,
>
> There are some concerns on 2.1 MVP approach, which have been raised

> herehttp://groups.google.com/group/google-web-toolkit/browse_thread/threa...
> and herehttp://groups.google.com/group/gwt-platform/browse_thread/thread/862c...

>
> To summarize, here are some quotes:
> * It's extremely fast to build an initial scaffold (CRUD for all
> entities), but I'm not sure how easy it is to customize it for real
> world usage
> * When skimming the generated sources I saw A LOT of artifacts, which
> I don't feel comfortable with because it means that although
> "officially" my code is not coupled with Roo, if I were to drop it I
> would have to manage all these generated artifacts myself.
> * This expenses example is a nightmare to follow.  The bindings/
> wiring  of all the pieces both client and server is nuts.
> * In M2, things have been cleaned up a bit
>
> I'm just trying to make sure the final MVP implementation will be
> usable without Roo and without automatic code generation, and will be

> at least as easy to use and understand ashttp://code.google.com/p/gwt-platform/

[Thomas Broyer]

On 9 juil, 11:31, "marius.andreiana" <marius.andrei...@gmail.com>
wrote:

> Hi GWT developers,
>
> There are some concerns on 2.1 MVP approach, which have been raised

> herehttp://groups.google.com/group/google-web-toolkit/browse_thread/threa...
> and herehttp://groups.google.com/group/gwt-platform/browse_thread/thread/862c...
>

> To summarize, here are some quotes:
> * It's extremely fast to build an initial scaffold (CRUD for all
> entities), but I'm not sure how easy it is to customize it for real
> world usage
> * When skimming the generated sources I saw A LOT of artifacts, which
> I don't feel comfortable with because it means that although
> "officially" my code is not coupled with Roo, if I were to drop it I
> would have to manage all these generated artifacts myself.
> * This expenses example is a nightmare to follow.  The bindings/
> wiring  of all the pieces both client and server is nuts.
> * In M2, things have been cleaned up a bit
>
> I'm just trying to make sure the final MVP implementation will be
> usable without Roo and without automatic code generation, and will be
> at least as easy to use and understand as http://code.google.com/p/gwt-platform/
> . Otherwise, should it be left as a separate project rather than
> default GWT approach?
> What do others, more knowledgeable persons than me, think?

I really do not approach the different features of 2.1 as a whole
"MVP" set of things: there's
- RequestFactory and ValueStore (I don't think ValueStore has any
real use besides RequestFactory, though I'd be happy to be proved
wrong) for a record-oriented client-server communication;
- Cell-based widgets for efficient data-backed lists, trees and
tables
- PlaceController as typed layer over History (objects rather than
strings, even though it's not yet plumbed to History, which at least
proves it can be used without it)
- ActivityManager as an "application controller" (to use the term
from the GWT tutorials) on top of PlaceController
- and on top of that, GWT provides some base activities plumbed with
RequestFactory
- and finally, though it's not documented at all, EditorSupport which
works with UiBinder in a view to generate "data-binding code" (as far
as I understood)

You're free to use any of them independently of the others.

[Philippe Beaudoin]

Thanks Thomas,

I'm glad to hear that... It seems like some of these could be
integrated in gwt-platform apps (i.e. Cell-based widgets, maybe even
the RequestFactory). I wish I had more time to look into this.

Philippe

> --
> 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.
>
>

[PhilBeaudoin]

Following an off-group discussion with Marius, he suggested that I
comment back on this thread regarding the fear of many gwt-platform
users and developers that the GWT MVP approach is too tightly linked
to SpringRoo and the idea that it can generate a lot of boilerplate
automatically. Do you think this apprehension is grounded, or that
GWT's MVP can lead to lean code even when written manually?

Cheers,

Philippe

On Jul 9, 1:25 pm, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

> Thanks Thomas,
>
> I'm glad to hear that... It seems like some of these could be
> integrated in gwt-platform apps (i.e. Cell-based widgets, maybe even
> the RequestFactory). I wish I had more time to look into this.
>
>    Philippe
>
>
>
> On Fri, Jul 9, 2010 at 1:12 PM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > On 9 juil, 11:31, "marius.andreiana" <marius.andrei...@gmail.com>
> > wrote:
> >> Hi GWT developers,
>

> >> There are some concerns on 2.1MVPapproach, which have been raised

> >> herehttp://groups.google.com/group/google-web-toolkit/browse_thread/threa...
> >> and herehttp://groups.google.com/group/gwt-platform/browse_thread/thread/862c...
>
> >> To summarize, here are some quotes:
> >> * It's extremely fast to build an initial scaffold (CRUD for all
> >> entities), but I'm not sure how easy it is to customize it for real
> >> world usage
> >> * When skimming the generated sources I saw A LOT of artifacts, which
> >> I don't feel comfortable with because it means that although
> >> "officially" my code is not coupled with Roo, if I were to drop it I
> >> would have to manage all these generated artifacts myself.
> >> * This expenses example is a nightmare to follow.  The bindings/
> >> wiring  of all the pieces both client and server is nuts.
> >> * In M2, things have been cleaned up a bit
>

> >> I'm just trying to make sure the finalMVPimplementation will be

> >> usable without Roo and without automatic code generation, and will be

> >> at least as easy to use and understand ashttp://code.google.com/p/gwt-platform/

[Thomas Broyer]

On 12 juil, 19:34, PhilBeaudoin <philippe.beaud...@gmail.com> wrote:
> Following an off-group discussion with Marius, he suggested that I
> comment back on this thread regarding the fear of many gwt-platform
> users and developers that the GWT MVP approach is too tightly linked
> to SpringRoo and the idea that it can generate a lot of boilerplate
> automatically. Do you think this apprehension is grounded, or that
> GWT's MVP can lead to lean code even when written manually?

First, it's a stated goal that RequestFactory/ValueStore is usable
"easily enough" without tooling such as Roo:
https://wave.google.com/wave/waveref/googlewave.com/w+WU4iAICkI
Key phrase: "this is definitely intended to be useful without Roo"

That being said, when you have many model objects, coding the as-many
Record interfaces and the @Service interfaces on the client-side is
cumbersome. This is going to change a bit though: M1 required a
ServerOperation enum for each @Service interface and a server-side
Config, M2 removes this using reflection on the server-side (as the
default implementation, because it's pluggable), and the goal is to
remove even more ("The Property types are cumbersome and we plan to
drop them").
We're starting prototyping, so it's OK to code those things by hand
(and play by the current limitations: I'm coding a server-side object
extending a model object just to add the findXxx, persist and remove
methods), but if it proves necessary (or just worth it), we'll use
generators, probably in the form of an annotation processor.
(FWIW, we're using Morphia on the server-side to persist POJOs into
MongoDB, which is quite similar what Objectify is for AppEngine
AFAICT)

Time will tell if RequestFactory fulfills its stated goal of being
"easy enough" to be used without Roo, but it's promising and I guess
only feedback from the community will help make it useful in as many
contexts as possible (proof that Gogle is listening: the
RequestFactoryServletHelper answers an early user request)