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 b
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 w
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.
On Fri, Sep 23, 2011 at 11:26 AM, wstrange wrot
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 wrote:
>
> I h
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.
--
You received this message becau
A good place to get started would be
http://code.google.com/p/acris/wiki/AnnotationProcessing_DebuggingEclipse
--
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/go
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
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
> Did almost the same, but as a Maven plugin that scans the classpath for
> classes extending a few base classe
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
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
> Many people using JPA/JDO or similar on the server-side already have DTOs
> and copy things from their entitie
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
w
On Fri, Sep 23, 2011 at 3:13 PM, magnum 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 do
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
On Sep 24, 2011, at 8:53 AM, Thomas Broyer wrote:
>
>
> 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 t
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
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 get
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 develo
On Sat, Sep 24, 2011 at 4:53 PM, Thomas Broyer 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 framewor
> 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 depl
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 wrote:
> On Sat, Sep 24, 2011 at 4:53 PM, Thomas Broyer wrote:
>
>> And BTW, MVP is a
Hi,
And gwt-platform:
-> http://code.google.com/p/gwt-platform/
Cheers
Rob
On Sep 27, 7:44 am, Felipe Martim Vieira
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 Sep 26, 2:49 pm, camerojo 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 le
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 interesti
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 wrote:
> Mvp4g looks good, certainly more concise than GWTP. W
+1 for mvp4g.
On Sat, Oct 1, 2011 at 3:18 PM, Rob wrote:
> 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
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 appea
On Friday, September 23, 2011 1:48:18 PM UTC-4, Thomas Broyer wrote:
>
> 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
> 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.
--
You received this message because you are subscribed to the Google Groups
"Google
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 f
29 matches
Mail list logo