I use the Eclipse-plugin to help me write the async, but that's got nothing to with my proposed dispatcher ... unless there's something you forgot to mention
Cheers, Henry On Jan 27, 6:31 am, Alexander <[email protected]> wrote: > You write async version of interface manualy? > > 2010/1/25 jarrod <[email protected]> > > > > > Have you looked at the GWT-SL library? This is the project I use to > > export my RPC services with Spring. It is blisteringly easy. > >http://gwt-widget.sourceforge.net/gwt-sl/reference-1.0/index.html#RPC > > > The great thing about this library is that (except for one line in > > your servlet context) configuration is completely annotation-driven! > > > I just place this line in my-servlet.xml: > > <bean class="org.gwtwidgets.server.spring.GWTHandler" /> > > > The GWTHandler works as a HandlerMapping, so it can be ordered among > > other HandlerMappings as you see fit. > > > Next, I can wire-up RPC services like so: > > > First, the RPC Interface > > > @RemoteServiceRelativePath("UserService.rpc") // service path for > > client side, relative to module path > > @GWTRequestMapping("/foo.bar.users.Users/UserService.rpc") // service > > path for server side, relative to context > > public interface RpcUserService extends RemoteService { > > > void deleteUser(String uid); > > > User getUser(String uid); > > > List<User> listUsers(); > > > void updateUser(User user); > > > } > > > And the accompanying Async version: > > > public interface RpcUserServiceAsync { > > > void deleteUser(String uid, AsyncCallback<Void> callback); > > > void getUser(String uid, AsyncCallback<User> callback); > > > void listUsers(AsyncCallback<List<User>> callback); > > > void updateUser(User user, AsyncCallback<Void> callback); > > > } > > > I won't go into the client side usage, but on the server side, it > > works just like this: > > > @Component // Spring auto-detects and wires up this POJO > > // because this is an RpcUserService, the GWTHandler will export it > > automatically! > > public class UserServiceImpl implements RpcUserService { > > > private UserService service; // some backing bean > > > �...@autowired > > UserServiceImpl(UserService service) { > > this.service = service; > > } > > > �...@override > > public void deleteUser(String uid) { > > this.service.deleteUser(uid); > > } > > > �...@override > > public User getUser(String uid) { > > return this.service.loadUser(uid); > > } > > > �...@override > > public List<User> listUsers() { > > return this.service.listUsers(0, 1000); > > } > > > �...@override > > public void updateUser(User user) { > > this.service.updateUser(user); > > } > > > } > > > In this case, my application already had a server side component > > (UserService) to handle my requests. My POJO here is just a stupid- > > simple wrapper around that backend service object. Your mileage may > > vary, though. > > > That's it! There are no additional "configurations" to do, regardless > > of how many RPC services you want to make available. If all of your > > service's dependencies are made known to the container through the > > @Component annotation, then you won't even have to configure those in > > a Spring config file... > > > I hope that helps solve the concern you're addressing. > > > On Jan 24, 2:06 pm, Henry <[email protected]> wrote: > > > The issue is that I have to maintain a DI configuration file. > > > If I have say 50 rpc services, then that means I'll have a DI file > > > with 50 lines of DI injection. > > > > Cheers, > > > Henry > > > > On Jan 24, 2:38 am, olivier nouguier <[email protected]> > > > wrote: > > > > > hi, > > > > I can't figure out what you consider an issue in using a DI dispatch. > > > > Just to understand :) > > > > > On Sun, Jan 24, 2010 at 8:15 AM, Henry <[email protected]> wrote: > > > > > I took a quick look at > > >http://code.google.com/p/orcades-gwt-spring/wiki/orcadesGWTSpringHandler > > > > > Not bad, but it still needs managed beans which is managed via a .xml > > > > > file or annotations. > > > > > I'm suggesting something that doesn't even need that ... > > > > > the caveat is that my soln uses a name-design pattern (which might > > not > > > > > be a caveat) > > > > > > Cheers, > > > > > Henry > > > > > > On Jan 23, 2:16 am, olivier nouguier <[email protected]> > > > > > wrote: > > > > > > Hi > > > > > > It's quite easy to implement a GWT dispatcher. At least with > > spring, > > > > > then > > > > > > use autoscan feature: > > >http://code.google.com/p/orcades-gwt-spring/wiki/orcadesGWTSpringHandler > > > > > > HIH > > > > > > > On Fri, Jan 22, 2010 at 7:13 PM, Henry <[email protected]> wrote: > > > > > > > So far, > > > > > > > > I found there are a few ways to redirect your serviceimpl, namley > > > > > > > 1) logic in web.xml > > > > > > > 2) gwt-dispatch > > > > > > > 3) various framework plugins (for struts, jsf) > > > > > > > > But each of these solns above require you to edit a config file > > (or > > > > > > > modify a java file with guice) > > > > > > > everytime you add a new serviceimpl. > > > > > > > Would it be possible to have an auto-config, so that if you > > follow the > > > > > > > standard naming > > > > > > > convention of > > > > > > > XXXService.java > > > > > > > XXXServiceAsync.java > > > > > > > XXXServiceImpl.java > > > > > > > > that you won't have to add any more configurations. > > > > > > > i.e. > > > > > > > the service endpoint is something like > > > > > > > /gwt/GwtNameDispatcher > > > > > > > > and GwtNameDispatcher is written so that it invokes the > > respective > > > > > > > ServiceImpl > > > > > > > w/o reading any configs files. GwtNameDispatcher knows which > > > > > > > ServiceImpl to invoke > > > > > > > based upon what Service object was passed in the GWT-RPC post > > param. > > > > > > > The caveat is that you must follow the > > > > > > > XXXService.java > > > > > > > XXXServiceAsync.java > > > > > > > XXXServiceImpl.java > > > > > > > pattern, but if I write such a GwtNameDispatcher beast, would > > this be > > > > > > > useful > > > > > > > to the GWT community? > > > > > > > Is there a better soln? > > > > > > > > Cheers, > > > > > > > Henry > > > > > > > > -- > > > > > > > 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]><google-web-toolkit%2Bunsubs > > [email protected]> > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]><google-web-toolkit%252Bu > > [email protected]> > > > > > > > > . > > > > > > > For more options, visit this group at > > > > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > > > > -- > > > > > > A coward is incapable of exhibiting love; it is the prerogative of > > the > > > > > > brave. > > > > > > -- > > > > > > Mohandas Gandhi > > > > > > -- > > > > > 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]><google-web-toolkit%2Bunsubs > > [email protected]> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > > -- > > > > A coward is incapable of exhibiting love; it is the prerogative of the > > > > brave. > > > > -- > > > > Mohandas Gandhi > > > -- > > 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. > > -- > Regards, > Alexander -- 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.
