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].
> 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.
