On 2 déc, 23:52, Jeff Chimene <[email protected]> wrote:
> Hi Thomas,
>
> I had stumbled upon this solution. However, you have an additional detail I
> don't understand: The split between
> interface MyModelObject
> and
> class MyModelObjectImpl extends JavaScriptObject implements MyModelObject
>
> What advantage does this gain? I think it has something to do w/. DI or
> testing, but I cannot see why one wouldn't do
> void get(AsyncCallback<MyModelObjectImpl> callback);
>
> i.e. don't use an interface, just do all templating via the class?
If I'd do this, then I'd be breaking the assumption that my RPC
interface could be implemented as a "real" GWT-RPC, because I'd be
exposing an "implementation detail" (MyModelObjectImpl extends
JavaScriptObject, which means it cannot be used on the server side, so
this cannot be GWT-RPC but only an attempt at making something looking
like GWT-RPC).
The idea is that if I want to use GWT-RPC instead of my own
implementation, it won't break the code using the service.
> Also, I
> see you're using @ImplementedBy. How does this differ from
> bind(new TypeLiteral<SessionReaderTxn<Session>>()
> {}).to(MockSessionReader.class);
It's equivalent to bind(MyServiceAsync.class).to
(MyServiceAsyncImpl.class) *except* that:
- because it's not explicit it's a "by default" binding (aka "JIT
binding"), which means that:
- it doesn't require a GIN module (my app is composed of several
GWT modules, so I'd have my application-level GIN module –injector
actually– to inherit the GIN modules of all inherited GWT module)
- it can be "overridden" by an explicit binding in a GIN module (we
build "sample" apps to allow manual testing of the whole MVP –
including the real view that'll be used in the app–, with sample
service implementations that don't do any network call but instead
return sample data that ideally cover all special cases that we could
find "in the real" later; without the need to have the data in a
database)
- it's easier to maintain than an explicit binding in a GIN
module ;-)
> There is a redundancy in the above that I haven't figured out how to factor
> out. Ideally, it should be either
> bind(new TypeLiteral<ReaderTxn<Session>>() {}).to(MockSessionReader.class);
> or
> bind(new TypeLiteral<SessionTxn<Reader>>() {}).to(MockSessionReader.class);
I'm sorry, I don't understand: what are "reader" and "session" here?
why is this using TypeLiteral?
The @ImplementedBy is on the MyServiceAsync interface, not the
AsyncCallback. The AsyncCallback is never injected by DI, I cannot see
a use case for it (would you DI your event handlers?), it's generally
implemented as an anonymous nested class, which also means it's
explicitly instantiated where it's defined, i.e. in the presenters.
--
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.
