too much code: GWT Development with Activities and Places

[magnum]

I am trying to understand and adopt the MVP good practices and
UIBinder alongside Activities, Places, Hisotry, Views,
Presenters ....

What strikes me is there seems to be too much code that does nothing.

Place is one example. In the MVP part 1 and part 2 examples we had
browser History modelled by a stack of Strings. What I didn't like is
the dispatching case / switch statement that compared tokens (history
strings) and instantiated new presenters / views. This looked already
over the top, plus string constants directly over the code is a big NO-
NO. Refactoring history tokens into string constants or if someone is
very anal enums should do the trick. I was wrong. Now we have Places
instead of string constants. Places have gotten glorified to the level
of having their own handler... So now, there is history and places
which do the same thing.... except possibly for places that don't have
a history token attached.

It looks to me we went from "smart-er" views / presenters to "dumber"
views / presenters with more anonymous inner classes (for handlers)
and confusing wiring boilerplate (MVP p1). MVP p2 saves some of the
inner class nonsense but introduces new interfaces for view and
presenter. These are supposed to help with development of alternative
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.

Currently my GWT code is 10x larger than my javascript code. And
javascript eclipse plugin editors and libratries / frameworks are
getting better rapidly.

I'd like to see a way to write GWT code that is only as verbose as JS.

thoughts?

Then to less ano
Similarly with all the extra inner classes in

[wstrange]

I have no answers, but I fully agree.   

GWT development is getting horrendously complex. I have been playing with the RequestFactory  - and while

I appreciate what it is trying to do, the number of interfaces and classes one has to deal with is staggering. 

Let's hope that Dart (or Dash, or whatever it is called) brings some sanity to client side development :-)

[Harpal Grover]

I agree with you guys completely. Sometimes too strict of an OOP approach can lead to lots of over-engineering. 

I guess it's all about striking a fine balance and knowing when to pick the battles you want to win and knowing when to concede defeat.

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

[Alfredo Quiroga-Villamil]

I have to agree about this here as well, the Request Factory implementation is something that requires a lot of boilerplate code. By the time one is done implementing all the stuff you forget you had to make a call to the server.

Alfredo

On Fri, Sep 23, 2011 at 11:26 AM, wstrange <warren....@gmail.com> wrote:

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

--
Alfredo Quiroga-Villamil

AOL/Yahoo/Gmail/MSN IM:  lawwton

[Jeff Larsen]

I've solved a lot of the boilerplate issues by writing an annotation processor to create my Proxies. I'd open source it, but I did it on my companies dime and they arne't interested in opensourcing projects. It is DEFINITELY worth the effort to do it though. 

[Jeff Larsen]

A good place to get started would be

http://code.google.com/p/acris/wiki/AnnotationProcessing_DebuggingEclipse

[Thomas Broyer]

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.

[Alain Ekambi]

In other words this requires some high level hacking just to bring Data form A to B.

I miss the simplicity in all this. GWT is becoming to over engineered imho.

2011/9/23 Thomas Broyer <t.br...@gmail.com>

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.

--

GWT API for  non Java based platforms

http://code.google.com/p/gwt4air/

http://www.gwt4air.appspot.com/

[Thomas Broyer]

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

[Alain Ekambi]

Well i agree with you that RF brings a lot of usefull features.

I just wish this could be done in a more simpler way. Like magnum said it s just too much code.

2011/9/24 Thomas Broyer <t.br...@gmail.com>

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.

[-sowdri-]

Once you know the stack, which might vary from company to company, one option is to write a Maven Archetype that generates the boilerplate required to get started. Which could well include your gwt-commons library, and a rich set of BaseClasses for places and activities.. which is what we are working on... 

And as maintaining a maven archetype is pretty simple, its worth giving a try, if a lot of new projects are coming across in the company,, 

[Aidan O'Kelly]

On Fri, Sep 23, 2011 at 3:13 PM, magnum <p.mag...@gmail.com> wrote:

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

[Thomas Broyer]

On Saturday, September 24, 2011 12:48:02 PM UTC+2, Aidan OK wrote:

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.

GWT is a toolkit, not a framework, so it cannot be otherwise.

You're free to not use widgets at all too (I believe most GWT-Query projects do not use widgets); and you could, technically, even replace the whole JRE emulation with your own (except for Longs probably).

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!

Are we expecting to see GPE provide Proxy/RequestContext generation in

the future for non-android apps?

See https://groups.google.com/d/topic/google-plugin-eclipse/L4rzC5xnzW4/discussion 

[Sridhar Vennela]

--

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.

[camerojo]

I also agree - I hope the Google folk look at this.

GWT is a wonderful concept, and we should all be very grateful for it,
but some of the implementation is certainly over engineered.

In particular I wish that more focus was given to fixing basic bugs
(of which there are quite a few) rather than coming up with new high
level architectural concepts.

Of course all developers would prefer to be playing around with new
concepts rather than fixing bugs in existing code, but production
software demands that basic debugging must always take priority.

[Gal Dolber]

I also agree, but I don't think google is responsable for improving the user framework on gwt. 

It is great that they put together uibinder, gwt-rpc, the editors framework and other goodies, but its your choice to use them or not.

I am personally happy with a strong gwt core, and that just keep getting better with each release.

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

--
Guit: Elegant, beautiful, modular and *production ready* gwt applications.

http://code.google.com/p/guit/

[Ali Jalal]

Hi,
I think future of GWT being threatened by 2 evil:

1. Big compile time (specially when size of module increase) which increase development time, and usually in compile time, developer will concentrates on subjects other than development (!) and it takes a few minutes to concentrates on development again.
2. Complex and excessive code.

For example, I used Spring Roo to generate code for an entity with 4 field (property or relation) based on GWT, Spring & Hibernate. It generates about 1600 line code just for CRUD (create-read-update-delete and search) operations (!). Spring Roo generated GWT code based on MVP and Activity&Places, UIBinder,...

Recently I designed a code generator based on GWT, Spring and Hibnerate. It generates about 700 line code for same entity, same operations and same functionality (but I don't use MVP, Places&Activities or RequestFactory). So it is possible to decrease complexity and size of code.

MVC pattern (predecessor of MVP) which introduced in 1990s by GoV (Buschmann et. al.) as an architectural pattern, but it was not used widely and now simpler versions of it are used. It shows that a complex pattern will not survives even it designed based on best OO principles.

MVP is a good pattern but if you used it, you should accept its complexity, So use it when is necessary. (there is no such thing as a free launch!)

[Aidan O'Kelly]

On Sat, Sep 24, 2011 at 4:53 PM, Thomas Broyer <t.br...@gmail.com> wrote:

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

[camerojo]

> I am personally happy with a strong gwt core, and that just keep getting
> better with each release.

I couldn't agree more Gal.

It is the bugs in the GWT core that I feel need to be strongly
prioritized. That is where any development resources that Google
assigns to GWT are most profitably deployed.

My worry is that I see those valuable resources being applied to new
high level architectural concepts which may or may not be useful to
users, while nasty reported bugs remain for months or even years in
the core functionality. A solid core is critical.

John

On Sep 26, 10:12 am, Gal Dolber <gal.dol...@gmail.com> wrote:
> I also agree, but I don't think google is responsable for improving the user
> framework on gwt.
> It is great that they put together uibinder, gwt-rpc, the editors framework
> and other goodies, but its your choice to use them or not.
>
> I am personally happy with a strong gwt core, and that just keep getting
> better with each release.
>

[Felipe Martim Vieira]

Maybe you should have a look at this:

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

[Rob]

Hi,

And gwt-platform:

-> http://code.google.com/p/gwt-platform/

Cheers
Rob

On Sep 27, 7:44 am, Felipe Martim Vieira <felipemar...@gmail.com>
wrote:

> Maybe you should have a look at this:
>
> http://code.google.com/p/mvp4g/
>
> I have never used it, but it looks like a great alternative to reduce
> the amount of work.
>
>
>
>
>
>
>
>
>

> On Mon, Sep 26, 2011 at 6:14 AM, Aidan O'Kelly <aida...@gmail.com> wrote:

[jscheller]

On Sep 26, 2:49 pm, camerojo <jadcpub-goo...@yahoo.com.au> wrote:

> It is the bugs in the GWT core that I feel need to be strongly
> prioritized. That is where any development resources that Google
> assigns to GWT are most profitably deployed.
>
> My worry is that I see those valuable resources being applied to new
> high level architectural concepts which may or may not be useful to
> users, while nasty reported bugs remain for months or even years in
> the core functionality. A solid core is critical.

I'm don't want to seem unappreciative by adding to a discussion that
might be a little critical, but I couldn't agree more strongly with
what John said above. I've struggled to get excited about much of the
GWT functionality since 2.2 came out and I keep hoping the focus will
change back to infrastructure rather than architecture.

Core functionality (date/timezone/calendar, drag and drop, etc.) and
weird compatibility problems (FireFox key events and similar) seem to
languish for so long. Arguably, much of this isn't Google's
responsibility, but the vision of GWT as a layer over all the browser
craziness implies these areas (along with regular GPE updates, no
matter how annoying Mozilla's policies) should be something of a
priority.

Beyond this, some people seem to make the case that third parties
should be filling the gap with various UI widgets, but the lifespan of
the various bits of code floating around out there makes using third
party parts problematic. I'm amazed at how much pre-2.0, listener-
centric code is still out there. I feel like I'm in jungle as soon as
I start looking around outside the toolkit. A stable set of core UI
widgets (masked text entry, date/time pickers, currency, etc.) would
go a long way towards making GWT easy to use to build meaningful apps
with a lower learning curve.

In a nutshell, I'd have been much more excited to see a healthy list
of compatibility fixes and a really nice timezone-savvy date/time
picker that I knew would be supported long term rather than all the
Roo stuff that came out recently.

Not that I don't appreciate everything that's already there, though.
GWT is awesome and I just hope to see it keep getting better.

[Tom Carchrae]

Mvp4g looks good, certainly more concise than GWTP.  When I started using the GWTP plugin and it generated so much code for me, I got scared.   GWTP would certainly be a good choice if you were following the google-suggested MVP for big applications. 

The comment discussion here is pretty interesting, with the GWTP and MVP4G authors defending their design choices.  http://code.google.com/p/mvp4g/wiki/Mvp4g_vs_GWTP

One day, I'd like to propose a competition with real cash prizes for "most  elegant MVP framework in GWT".    For example, in the comment thread above, it would be interesting to see experts in each framework develop a full (albeit simple) application in each framework.  (Oh, if you have some cash money now, I'd be pleased if you steal the idea and start this competition today!)

I keep wondering, why can't GWT have an MVC model that is as simple as Rails or PlayFramework? 

Tom

[Rob]

Hi,

-> it would be interesting to see ... a full (albeit simple)
application in each framework.

Take a look at this GWTP-based sample:

-> http://gwt-cx.com/serendipity/Serendipity.html

Cheers
Rob

On Sep 29, 11:05 pm, Tom Carchrae <t...@carchrae.net> wrote:
> Mvp4g looks good, certainly more concise than GWTP.  When I started using
> the GWTP plugin and it generated so much code for me, I got scared.   GWTP
> would certainly be a good choice if you were following the google-suggested
> MVP for big applications.
>
> The comment discussion here is pretty interesting, with the GWTP and MVP4G

> authors defending their design choices.http://code.google.com/p/mvp4g/wiki/Mvp4g_vs_GWTP

>
> One day, I'd like to propose a competition with real cash prizes for "most
>  elegant MVP framework in GWT".    For example, in the comment thread above,
> it would be interesting to see experts in each framework develop a full
> (albeit simple) application in each framework.  (Oh, if you have some cash
> money now, I'd be pleased if you steal the idea and start this competition
> today!)
>
> I keep wondering, why can't GWT have an MVC model that is as simple as Rails
> or PlayFramework?
>
> Tom
>
> On Mon, Sep 26, 2011 at 2:44 PM, Felipe Martim Vieira <
>
>
>
>
>
>
>
> felipemar...@gmail.com> wrote:
> > Maybe you should have a look at this:
>
> >http://code.google.com/p/mvp4g/
>
> > I have never used it, but it looks like a great alternative to reduce
> > the amount of work.
>

> > On Mon, Sep 26, 2011 at 6:14 AM, Aidan O'Kelly <aida...@gmail.com> wrote:
> > > On Sat, Sep 24, 2011 at 4:53 PM, Thomas Broyer <t.bro...@gmail.com>

[Subhrajyoti Moitra]

+1 for mvp4g. 

[Riley]

I use MVP straight out of the Google videos and docs, and I love it. When I need to swap a view in or out, or change a url structure, or change a bit of communication with the server, I go strictly to the 1-2 files involved, make the changes I need, and never fear that some hidden bug will appear somewhere else.  The Places/Activity framework works beautifully, and gives me the flexibility to navigate programmatically in response to events without having to put History-manipulating code anywhere but in my PlaceController.  We've got 46,000 lines of GWT code running now, and it's easy to debug, easy to maintain, and is really delivering on the cross-browser compatibility promise.

What I love about GWT is how loosely coupled the different frameworks are.  I started out with GWT-RPC, and then moved to RequestFactory.  Then I wanted to switch to a plain JSON format so that the API could be usable to others w/o RF, and so I chucked most of RF... but I could still use parts of it like AutoBean to make parsing a snap!  If I have to pay for this modularity with 3x the code size, I'll do it - I'm a one-man dev team and GWT helped me launch a complex data-processing app in a few months.

[David Vree]

Thomas -- You can have the best of both worlds by using the "generation gap" pattern.  This is a technique we used very successfully in the Flex world via the GraniteDS GAS3 code generator.  The idea is that you always generate the base classes on every build, but you also generate the concrete classes once.   What is key is that the next level base inherits from the previous level concrete!!  Thus your manual tweaks are persisted and you still get regeneration on every build...it was pure awesome!

[Ed]

> You can have the best of both worlds by using the "generation gap" pattern

Yep, that is nice way of doing that. 

Also "MyEclipse for Spring" of MyEclipse, that generates a Spring backend uses this technique.

[Elhanan]

i believe the the very nature of GWT's JRE emulation to javascript with combination with java's lack of closures, is the one causes the large code base. 

this is because the style of writing itself is extremely different then "regular" java writing.

take for example the mandate to write every function call to a server (RPC,JSON,RF etc..) as asynchronous, in other frameworks, you would have no calls to the server, just page reloads, (or jsp forwards), so it not exactly you gave much thought to actual process of calling a server resource, you just did it, it's like blinking, try to focus on each time you blink and becomes very annoying.

add to that, that for each AsyncCallBack you have to write an anonymous class (a poor standin for closures, which java scripts DOES have), and you get even MORE code. 

and speaking of server client, communication, because of the JRE emulation, you discover on many instances you can't really reuse some of the code or models you wrote on the server as they contain features which are not present client side, and the ONLY way to have some sort of linkage between the 2 sides is via use of annotations, so once again, something you took for granted, comes right back at ya.

so now you have to double the code for client server models, and use crap load amount of brackets just for fun of it. 

and when you try to reuse using generics , you find out the hard way that in some cases you have go through lots of hoops just to get that working right, once again because of the nature of GWT compile process.

so in a sense one might say that programming java in gwt, is unlike programming in other web frameworks, although the syntax is the same, you have to un-learn something you got used to over the years. 

so far i see that the current trend is to create "generators" for the boilerplate codes, via annotations, either to domain models or proxies, and i think that at least to make the work more streamlined google should (off-course) fix major bugs, but also load the GPE with a whole lot more of wizards, generators, re-factoring tools, to bridge this "gap" between regular java and gwt java, i mean it doesn't even have a wizard for creating RPC's  not to mention other calls like request factory. 

not to mention to COMPLETE lack of ide support the module xml file , but that's another rant entirely. 

and although i took a look at MVP4G and the likes, the problem is they were created prior to activities and places, so if you that with the current gwt, you actually have 2 frameworks for mvp.

also places don't really replace history, i think they actually use it behind the scenes.