Hi, could you possible re-cap on what problem this approach solves? I'm using UIBinder with mvp-presenter without inverting the dependencies in this way without any problems so I'm wondering what I'm missing.
Thanks, Matt. 2010/1/29 István Szoboszlai <[email protected]> > Hello Bryce, > > Are you using the approach you were describing in any project now with > success? If so it would be very appreciated if you could write some > sentences about your experiences. > I thing I like what you proposed, and I also think it is not a big drawback > that you have to inject the presenters 'execute' interface int he view by > hand. > > So I think I will give a chance to this approach. > > I'll write if I have any conclusion (good, or bad). > > Best - Istvan > > On Wed, Dec 30, 2009 at 1:55 AM, bryce cottam <[email protected]> wrote: > >> very similar, but I think I either wanted to keep the Execute >> interface on the Presenter (since the View is already dependent on a >> nested interface from the Presenter) or having it on a top level >> package. Come to think of it I think I tried to define the Execute >> interface inside the Presenter and the compiler didn't like that, so I >> wound up just making it a top level api Interface. I think this is >> more decoupled than the interface being nested in the View >> implementation, (since the Presenter is only dealing with interfaces >> defined either in it's self, or in a top level package) >> >> You are correct on the constructor injection though, you wouldn't be >> able to inject both via constructor arguments, however, in the >> Presenter constructor you could simply inject it's self into a setter >> on the Display: >> >> public MyPresenter(MyDisplay display) { >> display.setExecute(this); >> } >> >> I'm used to Spring-style injection, which usually leverages some kind >> of setter post-construction anyhow. You could even have some other >> class implement the Executer api that just had a reference to the >> Presenter instance, but that's a few levels of indirection for >> delegating method calls :) >> >> I guess it's a small trade off for me to self-inject in my constructor >> rather than having Guice inject me if I can reduce boiler plate code. >> >> I'm glad to hear you were at least considering my approach, it's nice >> to know i'm not way off in left field. >> >> -bryce >> >> >> On Tue, Dec 29, 2009 at 4:53 PM, FKereki <[email protected]> wrote: >> > I also gave a thought to your method, but in the end opted out... but >> > I guess it's where you are heading. >> > >> > In the same way that the View implements Display, an interface defined >> > in the Presenter class, Presenter could implement Execute, an >> > interface defined in the View class. >> > >> > The View should have a method allowing injection of the Execute >> > object; the Presenter would this "self injection" in its constructor. >> > >> > Then, whenever any event happened, the View handler would do getExecute >> > ( ).someMethod( ). >> > >> > You would do away with all anonymous classes, and each class (View, >> > Presenter) would implement an interface defined in the other class. >> > >> > The symmetry breaks down a bit because you cannot inject each object >> > in the other through their constructors (obviously!) >> > >> > Is this along the lines you were thinking? >> > >> > -- >> > >> > 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]<google-web-toolkit%[email protected]> >> . >> > 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> >> > > > -- > Best Regards > - István Szoboszlai > [email protected] | +36 30 432 8533 | inepex.com > > -- > 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]<google-web-toolkit%[email protected]> > . > 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 [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.
