On Wed, Dec 2, 2009 at 4:48 PM, Thomas Broyer <[email protected]> wrote:
> > > 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. > OK. I keep forgetting about Java RPC. > > > 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 ;-) > OK, I think I get that line of reasoning. I've committed to two GIN modules. However, I do like the JIT binding aspect. > > > 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 goal with TypeLiteral is to "color" an interface so that I can have one interface describing all HTTP GET requests (ReaderTxn), and another interface describing all HTTP PUT requests (WriterTxn). The "color" should give GIN the information it needs to bind the implementation based on the data type (aka "color") bind(new TypeLiteral<ReaderTxn<Session>>() {}).to(MockSessionReader.class); bind(new TypeLiteral<ReaderTxn<Authorization>>() {}).to(MockAuthorizationReader.class); I tried something like public interface ReaderTxn<?> { public get<Session> (String sessionId); public get<Authorization> (String username, String password); } But, as you know, the Session handler must implement the Authorization get() and vice versa. So now I just bury each of the above get() methods in an implementation of the data-type specific interface. An extension of the abstract Transaction class handles the rest of the HTTP machinery: public class AuthenticateReader extends Transaction implements AuthenticateReaderTxn This is probably clear as mud. Anyway, I'm back to SessionReaderTxn and AuthorizationReaderTxn, i.e. hard-coding the data type in the class name. The Type Literal is a holdover from an earlier attempt to have a one routine handle multiple types. > > 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. > I see what you're doing (in the hazy sense of recognizing an image rippling in a fun-house mirror). I'll have to try this with one of the members of the "model" package > -- > > 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.
