Thanks Nicolas for your answer. Most of the feedback we get from GWTP
users is very positive, but it's the opinion of people who decided not
to use it that will help us improve it!

Christian summarized it well when he said we want to keep following
GWT. We will support the IsWidget interface soon and remove the need
for view to support custom interfaces, so you will be able to use any
GWT widget (or your own Composite) as a view.

Regarding GWTP's uses of GWT generators, I haven't looked at the
mechanism GWT 2.1 uses to decouple event plumbing from presenter
instances. In my experience, this is required to allow lazy
instantiation and code splitting of presenters. I remember reading T.
Broyer saying he didn't care too much about this since his presenters
were small but, in my experience, presenters can sometime include
quite a bit of logic. In my opinion, being able to lazily instantiate
them and wake them up on specific events is necessary for scalability.
In GWTP this is done through proxys, in MVP4G it is done by defining
events within the global event bus, and I still have to look into the
precise way GWT 2.1 solves this problem.

Also, I think it's a bit unfair to call GWTP's code generation "magic"
when GWT relies on it for so many different things... But if you
really want to write proxys yourself, GWTP's allows it.

Out of curiosity, which version of GWTP did you try?

Cheers,

   Philippe


On Nov 7, 5:46 am, Christian Goudreau <[email protected]>
wrote:
> More info on my number 3 comment.
> I just saw a comment from Philippe saying that mixing activity and place is
> discouraged for the  moment. Comming from what I say in one, I think this
> comment will be more appropriate for future release :D
>
> Cheers,
>
> On Sun, Nov 7, 2010 at 7:42 AM, Christian Goudreau <
>
>
>
>
>
>
>
> [email protected]> wrote:
> > I just want to answer some of your concern :D
>
> > 1- We want to introduce and follow every release of Gwt. We already
> > introduced Gwt's evenbus instead of using ours and there's more changes on
> > the way. That's a long term engagement, even our contributor guideline
> > follows gwt.
> > 2- You don't like the proxy's magic ? You can create them :D Proxy are used
> > for lasy instantiation of presenters and to facilitate code splitting while
> > keeping everything decoupled.
> > 3- There's some way to do that with gwtp (PresenterWidget, proxy events).
> > But there's no reason  to only use Gwtp, even though we encourage it. I
> > think that activity manager can become handy for cases that we don't fully
> > support yet.
>
> > Cheers,
>
> > On Sun, Nov 7, 2010 at 6:49 AM, Nicolas Antoniazzi <
> > [email protected]> wrote:
>
> >> Hi Phillipe.
> >> i am going to try "ProviderBundle".
>
> >> I tried to migrate my application to gwtp just before the 2.1 release but
> >> I reverted my changes for 3 reasons :
>
> >> 1 - I prefer to not depend too much on an external framework. I love all
> >> new things that come in every new release of gwt and I am afraid that
> >> frameworks become unsupported or do not follow new features. I had the
> >> exemple of a friend who has prefered to use GXT instead of Pure GWT, and
> >> today, he cannot use UiBinder or the new Handler mechanism. He is still
> >> using the old listener way.
> >> Today, GWT has released the new Activity ~ MVP part, with their own Place
> >> system. At the moment, MVP of GWT seems less powerfull than the GWTP's one,
> >> but the syntax is different. And tomorrow, maybe that directions will be
> >> more different. So I prefer not taking the risk to have a situation like
> >> with GXT.
>
> >> 2 - Declaration of Presenter / View looks too much complicated to me (but
> >> it is a pure subjective vision :) ).
> >> All the generation of ProxyPlace are too magical for me or not enough...
> >> By instance, The automatic generation of a Place is something interesting,
> >> but in the same time, it is too complicated to generate. I do not like the
> >> fact to have to declare an interface which extends ProxyPlace, and
> >> references it in a type litteral. I would have prefered to just have
> >> something like :
>
> >> @Place("login");
> >> @RunAsync
> >> public class LoginActivity implement GwtpActivity<LoginActivity.Presenter>
>
> >> public inteface Presenter {
> >>  public void onLogin();
> >>  ...
> >> }
>
> >> or something similar.
> >> Today I prefer to stay on a manual code for this part instead of a "half
> >> generation" that is (in my opinion) too complicated to declare.
> >> Finally (for the code style part), I did not like the fact that we have to
> >> use a local Widget variable in View and returns it with a asWidget() method
> >> for UiBinder Views.
> >> Today with GWT 2.1, all widgets implements IsWidget and provides a
> >> asWidget(). But since we have to store a local instance of Widget inside of
> >> view for UiBinder, it cannot be done automatically, we have to override it.
> >> However, I understand that IsWidget was not ready when you first
> >> implemented it. But today, it does not solve the problem of the local 
> >> Widget
> >> variable.
>
> >> 3 - My application has two top div. One called "root" for the main part of
> >> my application, and one called "overlay" for all elements that comes like a
> >> filter over my root elements (to display overlay help, ...). They have both
> >> some css declaration on them.
> >> I did not find any way to reuse this system with GWTP. GWTP come with a
> >> RootPresenter and I wanted to use a second RootPresenter plugged on overlay
> >> div but it is not possible.
> >> ActivityManager are more flexible for this, they have a setDisplay()
> >> method to setup the top element to use.
>
> >> Well, Phillipe, all those things are just my personal feelings for my
> >> specifical needs. I think that GWTP is a great framework for a lot of
> >> people.
> >> Unfortunatly, in my case, I had to fight against it (maybe that it was a
> >> design problem, but I am not sure), and there was all the more subjective
> >> aspects (abouts framework overlay and code style) that made me go away.
>
> >> In any case, Phillipe and Christian, thanks for your great work .
> >> I am going to try ProviderBundle, maybe that I will be more comfortable
> >> with it :)
>
> >> Nicolas.
>
> >>  2010/11/7 PhilBeaudoin <[email protected]>
>
> >> Hi Nicolas,
>
> >>> If you start using AsyncProvider, you might be interested in GWTP's
> >>> ProviderBundle at some point. The problem of AsyncProvider is that it
> >>> may introduce too many split points, and you will often want to do
> >>> some manual optimization and group a few things together behind the
> >>> same split point. ProviderBundle makes that really easy to do.
>
> >>> ProviderBundle is totally usable without the rest of GWTP. (Although
> >>> I'd love to hear your reason for not using it. ;))
>
> >>> Cheers,
>
> >>>   Philippe
>
> >>> On Nov 6, 4:40 pm, Nicolas Antoniazzi <[email protected]>
> >>> wrote:
> >>> > Thanks Thomas, I implemented something similar to what you said (I
> >>> think)
> >>> > and it works fine ! All my activities are code splitted "automatically"
> >>> now.
>
> >>> > I used the AsyncProvider<T>.
> >>> > I used a gin version compiled by gwtp team that include the AsyncProxy
> >>> > (althouth that I do not use gwtp for severals resons, thanks to gwtp
> >>> dev for
> >>> > this :) ) .
>
> >>> > @Ashton, you can get it from here :
> >>>http://code.google.com/p/gwt-platform/http://code.google.com/p/gwt-pl...
>
> >>> > The usage of AsyncProvider<T> is very simple. It's exactly like a
> >>> normal
> >>> > Provider<T> instead that you have to give an AsyncCallback to the get()
> >>> > method.
> >>> > example :
>
> >>> > @Inject
> >>> > Provider<MyClass> myProvider;
>
> >>> > @Inject
> >>> > AsyncProvider<MyClass> myAsyncProvider;
>
> >>> > private MyClass instance1;
> >>> > private MyClass instance2;
>
> >>> > public void myMethod() {
> >>> >   // To get an instance without code splitting
> >>> >   instance1 = myProvider.get();
>
> >>> >   // To get an instance with code splitting
> >>> >   myAsyncProvider.get(new AsyncCallback<MyClass>() {
> >>> > �...@override
> >>> > public void onSuccess(MyClass result) {
> >>> >      instance2 = result;
> >>> >   }
> >>> >  }
> >>> > �...@override
> >>> > public void onFailure(Throwable caught) {
> >>> >  }
> >>> >   }
>
> >>> > In the previous example, instance1 is instanciated without code
> >>> splitting,
> >>> > instance2 with code splitting.
> >>> > This is just a small example to show you the syntax. This example is
> >>> very
> >>> > stupid since if you declare a class with a class Provider<MyClass> in
> >>> the
> >>> > same file than an AsyncProvider<MyClass>, MyClass code will not be code
> >>> > splitted.
>
> >>> > Now, just for people who would like to know how to implement an
> >>> > ActivityAsyncProxy, my implementation looks like this : (And it might
> >>> really
> >>> > not be the best one. Thomas, maybe that you have a better code to share
> >>> ;) )
>
> >>> > public class ActivityAsyncProxy<T> implements Activity {
>
> >>> > �...@inject
> >>> > private AsyncProvider<T> provider;
> >>> >  private boolean canceled = false;
> >>> > private Activity impl;
>
> >>> > @Override
> >>> >  public String mayStop() {
> >>> > if (impl != null) return impl.mayStop();
> >>> >  return null;
>
> >>> > }
>
> >>> > @Override
> >>> >  public void onCancel() {
> >>> > if (impl != null) {
> >>> >  impl.onCancel();} else {
> >>> >  canceled = true;
> >>> > }
>
> >>> >  }
>
> >>> > �...@override
> >>> > public void onStop() {
> >>> >  if (impl != null) {
> >>> > impl.onStop();
> >>> >  } else {
> >>> > canceled = true;
> >>> >  }
>
> >>> > }
>
> >>> > @Override
> >>> >  public void start(final AcceptsOneWidget panel, final EventBus
> >>> eventBus) {
> >>> >  provider.get(new AsyncCallback<T>() {
>
> >>> > �...@override
> >>> > public void onSuccess(T result) {
> >>> >  // Do not starts loaded activity if it has been canceled
> >>> >  if (!canceled) {
> >>> > impl = (Activity) result;
> >>> >  impl.start(panel, eventBus);}
>
> >>> >  }
>
> >>> > �...@override
> >>> > public void onFailure(Throwable caught) {
> >>> >  // TODO : send error message
>
> >>> > }
> >>> >  });
> >>> > }
> >>> > }
>
> >>> > Now, in my ActivityMapper :
>
> >>> > public class RootActivityMapper implements ActivityMapper {
>
> >>> > @Inject
> >>> >  Provider<ActivityAsyncProxy<LoginActivity>> loginActivityProvider;
>
> >>> > @Inject
> >>> >  Provider<ActivityAsyncProxy<ProfileActivity>> profileActivityProvider;
>
> >>> > @Inject
> >>> >  Provider<ActivityAsyncProxy<PrivacyActivity>> privacyActivityProvider;
>
> >>> > @Override
> >>> >  public Activity getActivity(Place place) {
> >>> > if (place instanceof LoginPlace) return loginActivityProvider.get();
> >>> >  if (place instanceof ProfilePlace) return
> >>> profileActivityProvider.get();
> >>> >  if (place instanceof PrivacyPlace) return
> >>> privacyActivityProvider.get();
>
> >>> > return null;
> >>> >  }
>
> >>> > }
>
> >>> > And that's all.
>
> >>> > Well, Just for information, I created my custom provider for
> >>> > ActivityAsyncProxy :
>
> >>> > public class ActivityAsyncProxyProvider<T extends Activity> implements
> >>> > Provider<ActivityAsyncProxy<T>> {
>
> >>> > @Inject
> >>> >  Provider<ActivityProxy<T>> provider;
>
> >>> > �...@override
> >>> > public ActivityAsyncProxy<T> get() {
> >>> >  return provider.get();
>
> >>> > }
> >>> > }
>
> >>> > Now, in my ActivityMapper, injection are less verbose :
>
> >>> > @Inject
> >>> > ActivityAsyncProxyProvider<LoginActivity> loginActivityProvider;
>
> >>> > @Inject
> >>> > ActivityAsyncProxyProvider<ProfileActivity>
>
> ...
>
> read more »

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to