confuse
Coolzy
http://borglin.net/gwt-project/?page_id=377 and google gwt wiki mvp.
which one should I follow?
PhilBeaudoin
is, I plan on doing a lot of refactoring to try different approaches.
Also, puzzlebazar is not a tutorial, but a somewhat large-scale
project with relatively clear requirements (it is a redevelopment of
jspuzzle). As such, it may be a good place to learn about how to
integrate MVP in a real-world scenario, from the ground up. Here are
my (somewhat preliminary) findings:
* gwt-dispatch looks like it fits its purpose to at T. I have only
done minor tweaks to it to get rid of some warning. Use it!
* gwt-presenter is an excellent basis, but even with the replace
branch its not quite right for my project. The low-level presenter
model is where I'm spending the most time right now. I may consider
packaging my solution once its done.
* UI-Binder is cool, but you definitely need to read
http://code.google.com/p/google-web-toolkit/issues/detail?id=4355 to
get it to work with internationalization.
* GIN and Guice are the coolest thing since sliced bread! However, its
a bit tricky to get your custom widget to run within UIBinder if it
requires injection (i.e. for client bundle). I use static injection as
a workaround.
That's all I can think off the top of my head. I suggest following all
three projects... And start your own because it's the only way to
learn!
On Feb 25, 4:58 am, Coolzy <second.co...@gmail.com> wrote:
> right now there are 3 type of mvp implementation, puzzlebazar,http://borglin.net/gwt-project/?page_id=377and google gwt wiki mvp.
Michael Weisser
On Feb 25, 1:58 pm, Coolzy <second.co...@gmail.com> wrote:
> right now there are 3 type of mvp implementation, puzzlebazar,http://borglin.net/gwt-project/?page_id=377and google gwt wiki mvp.
> which one should I follow?
I am more or less in the same situation and yes you are right the MVP
stuff (gwt-presenter, etc.) is a little bit confusing...
The other best of breed approuches like "guice", "gin" and "gwt-
dispatch" are relatively clear. For the gwt-dispatch project i would
recommend to use the svn trunk version, because the base classes don't
depend on guice anymore and "SpringFramework" support was added for
the backend side.
For the client presenter work i decided to go into coding phase now
and try myself which mvp approuch fits best for my little project. I
started with the gwt-presenter-replace branch but at the moment i
don't understand the whole "magic" behind in full detail - so next
days I will rearrange my client part, go back to the roots, and use
the google gwt "Contacts" sample as my basis.
So all the best for your project and if possible please keep me posted
on which mvp way you will go...
- Michael
PhilBeaudoin
> and try myself which mvp approuch fits best for my little project. I
> started with the gwt-presenter-replace branch but at the moment i
> don't understand the whole "magic" behind in full detail - so next
> days I will rearrange my client part, go back to the roots, and use
> the google gwt "Contacts" sample as my basis.
This is esentially what I did with PuzzleBazar. I think a lot of
people have struggled with the replace branch (or the trunk) of gwt-
presenter. In my opinion, their architecture is not quite right for
large projects. Also, it seems to rely very heavily on the event bus,
even for strongly coupled objects (like Presenter and Place), making
it hard to follow what's going on.
Because of that I have been struggling to enable lazy instantiation of
presenters (which is a basic requirement for code splitting). However,
this latest refactoring I just made seems to be hitting the nail on
the head. I would recommend you check out the
com.philbeaudoin.gwt.presenter package of r68 or above. The rest of
PuzzleBazar is a nice simple demo application too, which might help
you understand how to use it. Also, see my other post and the wiki
for more information.
> So all the best for your project and if possible please keep me posted
> on which mvp way you will go...
Yes. I'm interested also, as well as your own experimentations,
Michael.