David, The Apache Shindig project (reference implementation of OpenSocial) provides another approach for registering ActionHandlers. The Shindig OpenSocial API code uses a HandlerDispatcher to dispatch Action handling (as opposed to using the Servlet to do this directly). For application specific registration, you'd write an Application specific HandlerDispatcher and inject that Dispatcher into your RPC Servlet. Your RPC Servlet would then do any initial processing on RPC calls, and then retrieve the ActionHandler from the dispatcher and handle the request. In this case, as you build new Actions you simply add a new Handler (or update a previous one to Handle the new action, as desired).
I haven't tried implementing this same approach, but I don't see any issues with it at this point. Note that Shindig goes a bit farther as their Handlers pass of most processes to a Service Provider Interface that can be replaced with concrete implementation. You can find the source I referred to at the Shindig SVN repository (http://incubator.apache.org/shindig/source-repository.html) in /trunk/ java/social-api/src/main/java/org/apache/shindig/social/. Cheers, Jason On Jul 3, 8:18 pm, David Peterson <da...@randombits.org> wrote: > There are a couple of ways to go about it, and I'm not 100% happy with > my current solution as a 'best practice'. It's a bit convoluted, > really. Current I'm using Guice on the server-side, so I bind them to > 'ActionHandler.class', and then a post-config step pulls all > ActionHandler bindings and registers them to my ActionHandlerRegistry. > > Binding code: > > binder.bind( ActionHandler.class ).annotatedWith( Names.named > ( type.getName() ) ).to( type ).in( > Singleton.class ); > > Linking code: > > List<Binding<ActionHandler>> bindings = injector > .findBindingsByType( TypeLiteral.get > ( ActionHandler.class ) ); > > for ( Binding<ActionHandler> binding : bindings ) { > actionHandlerRegistry.addHandler( binding.getProvider().get() ); > > } > > A simpler way would be to have an eager singleton which is provided > the actionHandlerRegistry via injection and just adds whatever > handlers you want to it. > > David > > On Jul 4, 8:06 am, ClusterCougar <nwwe...@gmail.com> wrote: > > > > > Thanks David. That looks like a much better solution. The only reason > > I did all those generics was because I was still trying to wrap my > > head around the problem. Based on this, I've come up with some ideas > > I'm going to try to implement. How do you register your > > ActionHandlers? > > > On Jul 3, 8:55 am, David Peterson <da...@randombits.org> wrote: > > > > Hey ClusterCougar, > > > > I think your implementation is over-complicated. On the client side, > > > just stick to two basic interfaces (and concrete implementations there- > > > of) - Action and Result (I'm using 'Result' rather than 'Response' > > > because that is often used in HTTP-related APIs), or in your API, > > > IProcedure and IReturn. The IAttributes, IRemoteProcedure and other > > > interfaces are unnecessary. > > > > Then, on the server side, I've got 'ActionHandler' classes, which look > > > something like this: > > > > public interface ActionHandler<A extends Action<R>, R extends Result> > > > { > > > public Class<A> getActionType(); > > > > public R execute( A action ) throws Exception; > > > > } > > > > You then register your various ActionHandler instances with your > > > 'RPCService' and it just matches up the action passed in with the > > > appropriate action handler, calls execute and you're off to the races. > > > > Sorry about the incomplete example - the code itself is tied up in the > > > app I'm using this in at the moment. I hope to make it a bit more > > > general down the track. > > > > David > > > > On Jun 30, 8:05 pm, ClusterCougar <nwwe...@gmail.com> wrote: > > > > > I thought I posted this last night, but I don't see it. Apologies if > > > > this is a dupe. > > > > > I've tried to implement thecommandpatternusing generics, but have > > > > some hangups. You can see my code at > > > > >http://code.google.com/p/gwt-command-pattern/ > > > > > Hangups: > > > > > 1) Too many parameters. It's just not pretty > > > > 2) I have to parameterize the RPCServiceAsync at the class level, > > > > whereas I would like to parameterize at the method level. This is a > > > > constraint of the compiler. > > > > 3) All my server-side code actually resides on the client side, > > > > because of the aggressive nature of the GWT compiler. I would add my > > > > voice again asking for a simple annotation or annotations like > > > > > on a class: @GWTIgnoreReference(ServerSideClass.class) > > > > and/or a method: @GWTIgnoreMethod > > > > > I think there are many justifiable use cases for this type of thing, > > > > and I can't think of any way it would decrease user experience. Does > > > > anyone know if this is a planned feature? Any comments/suggestions on > > > > how to remediate the problems above that I don't know of? Ray Ryan, > > > > are you listening? > > > > > Thanks, > > > > > On Jun 25, 4:07 pm, Eric <erjab...@gmail.com> wrote: > > > > > > On Jun 25, 5:12 pm, Herme Garcia <hgar...@peoplecall.com> wrote: > > > > > > > Hi, > > > > > > > After listening carefully Google IO's session from Ray Ryan about > > > > > > "Best PracticesFor Architecting Your GWT App" : > > > > > > >http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkit... > > > > > > > He suggests acommandpatternimplementation for RPC calling (see > > > > > > slides 21-25) they are using in Wave. > > > > > > Ray, > > > > > > If you're reading this, can you tell us if the full code for your > > > > > contact > > > > > manager is available anywhere? Also, the second of the "Contact > > > > > DIsplay UI" > > > > > slides has the line > > > > > > currentContactId = currentContactId; --~--~---------~--~----~------------~-------~--~----~ 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-Toolkit@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 -~----------~----~----~----~------~----~------~--~---
