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 <mrsz...@gmail.com>
> 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 <bcot...@gmail.com> 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 <fker...@gmail.com> 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
>> google-web-tool...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com>
>> .
>> > 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 google-web-tool...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>>
>>
>
>
> --
> Best Regards
> - István Szoboszlai
> istvan.szobosz...@inepex.com | +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 google-web-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com>
> .
> 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 google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
