concerns on 2.1 MVP approach
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? -- 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.
Re: concerns on 2.1 MVP approach
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" 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/ > . Otherwise, should it be left as a separate project rather than > default GWT approach? > What do others, more knowledgeable persons than me, think? -- 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.
Re: concerns on 2.1 MVP approach
On 9 juil, 11:31, "marius.andreiana" 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. -- 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.
Re: concerns on 2.1 MVP approach
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 wrote: > > On 9 juil, 11:31, "marius.andreiana" > 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. > > -- > 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. > > -- 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.
Re: concerns on 2.1 MVP approach
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 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 wrote: > > > On 9 juil, 11:31, "marius.andreiana" > > 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/ > >> . 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. > > > -- > > 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 > > athttp://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 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.
Re: concerns on 2.1 MVP approach
On 12 juil, 19:34, PhilBeaudoin 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)
--
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.
