Re: Best practice to implement Command Pattern RPC on server?
On Jul 8, 8:03 am, pohl pohl.longs...@gmail.com wrote:
Essentially, I couldn't get the GWT compiler to work with a service
with the following definition:
public interface DispatchService extends RemoteService {
A extends ActionR, R extends Result R execute( A action )
throws Exception;
}
I tried to do the same thing, inspired by Ray Ryan's talk at Google I/
O.
Did you file an issue to track this defect? In my opinion, the
Javascript compiler should do the right thing if it can.
Perhaps this is the same as Issue 2374?
http://code.google.com/p/google-web-toolkit/issues/detail?id=2374
Yeah, that looks like the same issue.
That said, it probably wouldn't change the design too much if the bug
wasn't there - there are some other reasons to have DispatchAsync as a
separate class anyway, including but not limited making it easier to
inject via Ginjector.
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Hi Nathan,
On Jul 7, 7:24 am, Nathan Wells nwwe...@gmail.com wrote:
I think this is mostly directed at David, but if anyone has answers,
I'd welcome them.
In your command pattern implementation or somewhere on this thread
(can't remember where I saw it) you mention that GWT doesn't properly
implement parameterized method calls on the RPC service. Is that true,
or did I misunderstand something? I think you also mentioned that that
is in fact desirable, since you would want one service per procedure
call. Can you explain that a little more? I'm not sure I understood.
Essentially, I couldn't get the GWT compiler to work with a service
with the following definition:
public interface DispatchService extends RemoteService {
A extends ActionR, R extends Result R execute( A action )
throws Exception;
}
It was complaining about generic method matching, which I am guessing
means that whatever magic is going on with generators for
RemoteServices doesn't correctly handle having the 'A extends
ActionR, R extends Result' parameter generic definition. It works
fine if I just make it:
Result extends ( Action? action ) throws Exception;
But I lose the handy type-casting from this one.
Anyway, the workaround I have works ok, it's just a little less
direct. No big deal...
Oh, and I updated my annotation to take a Class? rather than a
String literal, thanks for the tip.
Ah, ok. Glad it's working :)
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Martin, For really simple example you can see here: http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pattern-on-server.html At the end, you will need to add some more code, but you can see how the pattern works (it helped me!) Herme On Jul 5, 10:16 am, martinhansen martin.hanse...@googlemail.com wrote: Hello David, I've read your source code and your example. It is very interesting. But although it's short and simple, I still don't understand it. Especially GIN and GUICE confuses me a lot. Can I use your example without these technologies? Does anyone know a really simple example? The example in Ray's sheet is interesting and simple, but incomplete. Where does the actual action take place in his example, let's say, querying some contact details from a remote data base? I think this important part is missing. The ContactService defines a method called execute, but where is this method implemented? Is it implemented automatically by some mechanism? If yes, how is it done? Is execute the only method in the interface I ever need, e.g. some kind of place holder? Any help would be greatly appreciated. On 5 Jul., 08:17, David Peterson da...@randombits.org wrote: Hi Nathan, On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote: I updated my project to only use the two interfaces as suggested by David. Instead of using actionhandlers and registering them, I created an annotation for the IRemoteProcedureCall implementations that contains the canonical class name of the IProcedure that is to be run on the server. As you say, one of the downsides of linking the handler to the concrete implementation is that there may be issues with the GWT compiler. That said, in general it seems to mostly ignore attributes, so it may not be an issue. The other downside for me is that it ties the action interface to a specific implementation. This makes it more difficult to write mocks for tests, etc. Having them configured purely on the server-side means you can replace them with whatever you like on in test scenarios. Or, if you want to provide alternate implementations (eg. JDO vs Hibernate), you can have both in your app and just switch between them by changing your DI configuration. The downside of my method is that you may forget to actually implement the handler. Of course, this will generally show up pretty quickly when you try to actually use it. And I guess it's still quite easy to forget to supply the annotation anyway... David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Hello Herme,
your example is very interesting. I downloaded it and changed it to
work with GWT. But I was not successful. When I run my application,
the compiler complains about my client service interface:
[ERROR] Type 'com.isp.gwtpattern.client.rpc.Response' was not
serializable and has no concrete serializable subtypes
The code is as follows:
@RemoteServiceRelativePath( buchungServlet )
public interface BuchungService extends RemoteService {
T extends Response T execute(ActionT action);
}
What am I doing wrong here? My interfaces Action and Response both
implement IsSerializable.
M
On 5 Jul., 11:55, hgarciag hgarc...@gmail.com wrote:
Martin,
For really simple example you can see here:
http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat...
At the end, you will need to add some more code, but you can see how
the pattern works (it helped me!)
Herme
On Jul 5, 10:16 am, martinhansen martin.hanse...@googlemail.com
wrote:
Hello David,
I've read your source code and your example. It is very interesting.
But although it's short and simple, I still don't understand it.
Especially GIN and GUICE confuses me a lot. Can I use your example
without these technologies?
Does anyone know a really simple example? The example inRay'ssheet
is interesting and simple, but incomplete. Where does the actual
action take place in his example, let's say, querying some contact
details from a remote data base? I think this important part is
missing.
The ContactService defines a method called execute, but where is
this method implemented? Is it implemented automatically by some
mechanism? If yes, how is it done? Is execute the only method in the
interface I ever need, e.g. some kind of place holder?
Any help would be greatly appreciated.
On 5 Jul., 08:17, David Peterson da...@randombits.org wrote:
Hi Nathan,
On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote:
I updated my project to only use the two interfaces as suggested by
David. Instead of using actionhandlers and registering them, I created
an annotation for the IRemoteProcedureCall implementations that
contains the canonical class name of the IProcedure that is to be run
on the server.
As you say, one of the downsides of linking the handler to the
concrete implementation is that there may be issues with the GWT
compiler. That said, in general it seems to mostly ignore attributes,
so it may not be an issue.
The other downside for me is that it ties the action interface to a
specific implementation. This makes it more difficult to write mocks
for tests, etc. Having them configured purely on the server-side means
you can replace them with whatever you like on in test scenarios. Or,
if you want to provide alternate implementations (eg. JDO vs
Hibernate), you can have both in your app and just switch between them
by changing your DI configuration.
The downside of my method is that you may forget to actually implement
the handler. Of course, this will generally show up pretty quickly
when you try to actually use it. And I guess it's still quite easy to
forget to supply the annotation anyway...
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Hello Herme, now it finally works. I've used your great and simple example and created a simple GWT application from it to check a user name and a password. For anyone interested, I've uploaded the sample application. It's essentially the same, just using GWT. http://rapidshare.de/files/47769639/GWTPattern.zip.html On 5 Jul., 11:59, Herme Garcia hgar...@peoplecall.com wrote: Martin, For really simple example, look at http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat... This is really simple, far from complete, but you can see how the pattern works Herme On Jul 5, 10:16 am, martinhansen martin.hanse...@googlemail.com wrote: Hello David, I've read your source code and your example. It is very interesting. But although it's short and simple, I still don't understand it. Especially GIN and GUICE confuses me a lot. Can I use your example without these technologies? Does anyone know a really simple example? The example inRay'ssheet is interesting and simple, but incomplete. Where does the actual action take place in his example, let's say, querying some contact details from a remote data base? I think this important part is missing. The ContactService defines a method called execute, but where is this method implemented? Is it implemented automatically by some mechanism? If yes, how is it done? Is execute the only method in the interface I ever need, e.g. some kind of place holder? Any help would be greatly appreciated. On 5 Jul., 08:17, David Peterson da...@randombits.org wrote: Hi Nathan, On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote: I updated my project to only use the two interfaces as suggested by David. Instead of using actionhandlers and registering them, I created an annotation for the IRemoteProcedureCall implementations that contains the canonical class name of the IProcedure that is to be run on the server. As you say, one of the downsides of linking the handler to the concrete implementation is that there may be issues with the GWT compiler. That said, in general it seems to mostly ignore attributes, so it may not be an issue. The other downside for me is that it ties the action interface to a specific implementation. This makes it more difficult to write mocks for tests, etc. Having them configured purely on the server-side means you can replace them with whatever you like on in test scenarios. Or, if you want to provide alternate implementations (eg. JDO vs Hibernate), you can have both in your app and just switch between them by changing your DI configuration. The downside of my method is that you may forget to actually implement the handler. Of course, this will generally show up pretty quickly when you try to actually use it. And I guess it's still quite easy to forget to supply the annotation anyway... David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Yeah, that took me a while to figure out too - I do mention that on
the 'Getting Started' example for gwt-dispatch. Better error messages
would definitely be helpful...
David
On Jul 6, 8:17 pm, martinhansen martin.hanse...@googlemail.com
wrote:
Gr!
I found out why! Gr!
The Action and Response classes must have an empty default constructor
to be serializable. I've had this error before. Unfortunately, the GWT
compiler error message is anything but helpful in this case. G.
On 6 Jul., 11:57, martinhansen martin.hanse...@googlemail.com wrote:
Hello Herme,
your example is very interesting. I downloaded it and changed it to
work with GWT. But I was not successful. When I run my application,
the compiler complains about my client service interface:
[ERROR] Type 'com.isp.gwtpattern.client.rpc.Response' was not
serializable and has no concrete serializable subtypes
The code is as follows:
@RemoteServiceRelativePath( buchungServlet )
public interface BuchungService extends RemoteService {
T extends Response T execute(ActionT action);
}
What am I doing wrong here? My interfaces Action and Response both
implement IsSerializable.
M
On 5 Jul., 11:55, hgarciag hgarc...@gmail.com wrote:
Martin,
For really simple example you can see here:
http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat...
At the end, you will need to add some more code, but you can see how
the pattern works (it helped me!)
Herme
On Jul 5, 10:16 am, martinhansen martin.hanse...@googlemail.com
wrote:
Hello David,
I've read your source code and your example. It is very interesting.
But although it's short and simple, I still don't understand it.
Especially GIN and GUICE confuses me a lot. Can I use your example
without these technologies?
Does anyone know a really simple example? The example inRay'ssheet
is interesting and simple, but incomplete. Where does the actual
action take place in his example, let's say, querying some contact
details from a remote data base? I think this important part is
missing.
The ContactService defines a method called execute, but where is
this method implemented? Is it implemented automatically by some
mechanism? If yes, how is it done? Is execute the only method in the
interface I ever need, e.g. some kind of place holder?
Any help would be greatly appreciated.
On 5 Jul., 08:17, David Peterson da...@randombits.org wrote:
Hi Nathan,
On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote:
I updated my project to only use the two interfaces as suggested by
David. Instead of using actionhandlers and registering them, I
created
an annotation for the IRemoteProcedureCall implementations that
contains the canonical class name of the IProcedure that is to be
run
on the server.
As you say, one of the downsides of linking the handler to the
concrete implementation is that there may be issues with the GWT
compiler. That said, in general it seems to mostly ignore attributes,
so it may not be an issue.
The other downside for me is that it ties the action interface to a
specific implementation. This makes it more difficult to write mocks
for tests, etc. Having them configured purely on the server-side means
you can replace them with whatever you like on in test scenarios. Or,
if you want to provide alternate implementations (eg. JDO vs
Hibernate), you can have both in your app and just switch between them
by changing your DI configuration.
The downside of my method is that you may forget to actually implement
the handler. Of course, this will generally show up pretty quickly
when you try to actually use it. And I guess it's still quite easy to
forget to supply the annotation anyway...
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Thought I'd point to my command pattern examples:
http://github.com/jdwyah/tocollege.net/tree/f97ed4ff3f31c1c463eb426c34a55de439c601b3/src/main/java/com/apress/progwt/client/domain/commands
I found the command pattern to be just the ticket to deal with XSRF
attacks. In the directory above you can see my AbstractCommand class
and a number of Command subclasses. I ended up creating a
CommandService class as well, which would have different affects on
the client and server (basically it would persist entities when on the
server and just execute logic when on the client).
Cheers,
-Jeff
On Jul 6, 6:17 am, martinhansen martin.hanse...@googlemail.com
wrote:
Gr!
I found out why! Gr!
The Action and Response classes must have an empty default constructor
to be serializable. I've had this error before. Unfortunately, the GWT
compiler error message is anything but helpful in this case. G.
On 6 Jul., 11:57, martinhansen martin.hanse...@googlemail.com wrote:
Hello Herme,
your example is very interesting. I downloaded it and changed it to
work with GWT. But I was not successful. When I run my application,
the compiler complains about my client service interface:
[ERROR] Type 'com.isp.gwtpattern.client.rpc.Response' was not
serializable and has no concrete serializable subtypes
The code is as follows:
@RemoteServiceRelativePath( buchungServlet )
public interface BuchungService extends RemoteService {
T extends Response T execute(ActionT action);
}
What am I doing wrong here? My interfaces Action and Response both
implement IsSerializable.
M
On 5 Jul., 11:55, hgarciag hgarc...@gmail.com wrote:
Martin,
For really simple example you can see here:
http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat...
At the end, you will need to add some more code, but you can see how
the pattern works (it helped me!)
Herme
On Jul 5, 10:16 am, martinhansen martin.hanse...@googlemail.com
wrote:
Hello David,
I've read your source code and your example. It is very interesting.
But although it's short and simple, I still don't understand it.
Especially GIN and GUICE confuses me a lot. Can I use your example
without these technologies?
Does anyone know a really simple example? The example inRay'ssheet
is interesting and simple, but incomplete. Where does the actual
action take place in his example, let's say, querying some contact
details from a remote data base? I think this important part is
missing.
The ContactService defines a method called execute, but where is
this method implemented? Is it implemented automatically by some
mechanism? If yes, how is it done? Is execute the only method in the
interface I ever need, e.g. some kind of place holder?
Any help would be greatly appreciated.
On 5 Jul., 08:17, David Peterson da...@randombits.org wrote:
Hi Nathan,
On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote:
I updated my project to only use the two interfaces as suggested by
David. Instead of using actionhandlers and registering them, I
created
an annotation for the IRemoteProcedureCall implementations that
contains the canonical class name of the IProcedure that is to be
run
on the server.
As you say, one of the downsides of linking the handler to the
concrete implementation is that there may be issues with the GWT
compiler. That said, in general it seems to mostly ignore attributes,
so it may not be an issue.
The other downside for me is that it ties the action interface to a
specific implementation. This makes it more difficult to write mocks
for tests, etc. Having them configured purely on the server-side means
you can replace them with whatever you like on in test scenarios. Or,
if you want to provide alternate implementations (eg. JDO vs
Hibernate), you can have both in your app and just switch between them
by changing your DI configuration.
The downside of my method is that you may forget to actually implement
the handler. Of course, this will generally show up pretty quickly
when you try to actually use it. And I guess it's still quite easy to
forget to supply the annotation anyway...
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Hi Nathan, On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote: I updated my project to only use the two interfaces as suggested by David. Instead of using actionhandlers and registering them, I created an annotation for the IRemoteProcedureCall implementations that contains the canonical class name of the IProcedure that is to be run on the server. As you say, one of the downsides of linking the handler to the concrete implementation is that there may be issues with the GWT compiler. That said, in general it seems to mostly ignore attributes, so it may not be an issue. The other downside for me is that it ties the action interface to a specific implementation. This makes it more difficult to write mocks for tests, etc. Having them configured purely on the server-side means you can replace them with whatever you like on in test scenarios. Or, if you want to provide alternate implementations (eg. JDO vs Hibernate), you can have both in your app and just switch between them by changing your DI configuration. The downside of my method is that you may forget to actually implement the handler. Of course, this will generally show up pretty quickly when you try to actually use it. And I guess it's still quite easy to forget to supply the annotation anyway... David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Hello David, I've read your source code and your example. It is very interesting. But although it's short and simple, I still don't understand it. Especially GIN and GUICE confuses me a lot. Can I use your example without these technologies? Does anyone know a really simple example? The example in Ray's sheet is interesting and simple, but incomplete. Where does the actual action take place in his example, let's say, querying some contact details from a remote data base? I think this important part is missing. The ContactService defines a method called execute, but where is this method implemented? Is it implemented automatically by some mechanism? If yes, how is it done? Is execute the only method in the interface I ever need, e.g. some kind of place holder? Any help would be greatly appreciated. On 5 Jul., 08:17, David Peterson da...@randombits.org wrote: Hi Nathan, On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote: I updated my project to only use the two interfaces as suggested by David. Instead of using actionhandlers and registering them, I created an annotation for the IRemoteProcedureCall implementations that contains the canonical class name of the IProcedure that is to be run on the server. As you say, one of the downsides of linking the handler to the concrete implementation is that there may be issues with the GWT compiler. That said, in general it seems to mostly ignore attributes, so it may not be an issue. The other downside for me is that it ties the action interface to a specific implementation. This makes it more difficult to write mocks for tests, etc. Having them configured purely on the server-side means you can replace them with whatever you like on in test scenarios. Or, if you want to provide alternate implementations (eg. JDO vs Hibernate), you can have both in your app and just switch between them by changing your DI configuration. The downside of my method is that you may forget to actually implement the handler. Of course, this will generally show up pretty quickly when you try to actually use it. And I guess it's still quite easy to forget to supply the annotation anyway... David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Martin, For really simple example, look at http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pattern-on-server.html This is really simple, far from complete, but you can see how the pattern works Herme On Jul 5, 10:16 am, martinhansen martin.hanse...@googlemail.com wrote: Hello David, I've read your source code and your example. It is very interesting. But although it's short and simple, I still don't understand it. Especially GIN and GUICE confuses me a lot. Can I use your example without these technologies? Does anyone know a really simple example? The example in Ray's sheet is interesting and simple, but incomplete. Where does the actual action take place in his example, let's say, querying some contact details from a remote data base? I think this important part is missing. The ContactService defines a method called execute, but where is this method implemented? Is it implemented automatically by some mechanism? If yes, how is it done? Is execute the only method in the interface I ever need, e.g. some kind of place holder? Any help would be greatly appreciated. On 5 Jul., 08:17, David Peterson da...@randombits.org wrote: Hi Nathan, On Jul 5, 2:15 am, Nathan Wells nwwe...@gmail.com wrote: I updated my project to only use the two interfaces as suggested by David. Instead of using actionhandlers and registering them, I created an annotation for the IRemoteProcedureCall implementations that contains the canonical class name of the IProcedure that is to be run on the server. As you say, one of the downsides of linking the handler to the concrete implementation is that there may be issues with the GWT compiler. That said, in general it seems to mostly ignore attributes, so it may not be an issue. The other downside for me is that it ties the action interface to a specific implementation. This makes it more difficult to write mocks for tests, etc. Having them configured purely on the server-side means you can replace them with whatever you like on in test scenarios. Or, if you want to provide alternate implementations (eg. JDO vs Hibernate), you can have both in your app and just switch between them by changing your DI configuration. The downside of my method is that you may forget to actually implement the handler. Of course, this will generally show up pretty quickly when you try to actually use it. And I guess it's still quite easy to forget to supply the annotation anyway... David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
On Jul 5, 6:16 pm, martinhansen martin.hanse...@googlemail.com
wrote:
Hello David,
I've read your source code and your example. It is very interesting.
But although it's short and simple, I still don't understand it.
Especially GIN and GUICE confuses me a lot. Can I use your example
without these technologies?
You can use the classes directly, but if you can figure out Guice, it
will save you a fair bit of work in the long run. There is a bit of a
learning curve though. The main things you will need to configure if
you want to do it manually:
Server side:
Provide an instance of 'ActionHandlerRegistry' and 'Dispatch' (you can
use 'DefaultDispatch' for a simple implementation) as a singleton:
public class MyManager {
private static final ActionHandlerRegistry REGISTRY;
private static final Dispatch DISPATCH;
public static Dispatch getDispatch() {
if ( DISPATCH == null ) {
REGISTRY = new DefaultActionHandlerRegistry();
DISPATCH = new DefaultDispatch();
REGISTRY.addHandler( new MyCustomHandler() );
REGISTRY.addHandler( new MyOtherHandler() );
}
return DISPATCH;
}
}
You will also need a subclass of 'DispatchServiceServlet'. Eg:
public class MyDispatchServiceServlet extends DispatchServiceServlet {
public MyDispatchServiceServlet() {
super( MyManager.getDispatch() );
}
}
Then hook that up in the appropriate place for your GWT connection.
On the server side, you just need an instance of 'DispatchAsync'.
Again, 'DefaultDispatchAsync' should do the trick. Eg:
private final static DispatchAsync DISPATCH = new DefaultDispatchAsync
();
Provide an accessor for that to your other classes and off you go.
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
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:
ListBindingActionHandler bindings = injector
.findBindingsByType( TypeLiteral.get
( ActionHandler.class ) );
for ( BindingActionHandler 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 ActionHandlerA extends ActionR, R extends Result
{
public ClassA 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,
Re: Best practice to implement Command Pattern RPC on server?
All,
Ok, just relooked and apparently the approach I described above was
part of the 0.8 Shindig release, not the current 0.9. The pattern is
still similar, but the implementation is a bit more confusing if you
look at the Shindig code directly. Other than the references above to
the Shindig source locations, the approach for the most part still
stands (the code is just built with more complex dependency
injection).
Respectfully,
Jason
On Jul 4, 7:42 am, Jason A. Beranek jason.bera...@gmail.com wrote:
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:
ListBindingActionHandler bindings = injector
.findBindingsByType( TypeLiteral.get
( ActionHandler.class ) );
for ( BindingActionHandler 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 ActionHandlerA extends ActionR, R extends Result
{
public ClassA 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
Re: Best practice to implement Command Pattern RPC on server?
Jason: I'll admit I was unable to figure out exactly what Shindig's
approach is, exactly, unfortunately. However there is definitely more
than one way to skin this cat. My current implementation an Action, a
Result and a Handler for each operation. This does result in some
class proliferation, but has the upside of having everything nicely
self-contained.
In my implementation, I actually have a 'Dispatch' class which can be
injected directly, and a separate DispatchServiceServlet which is also
injected the same Dispatch instance and provides access from GWT/RPC.
To hold you over while I get the code sorted, here is a simple example
of what an action/result/handler looks like:
It's just a concrete implementation of ActionHandler. Essentially,
each Action/Result has a single ActionHandler that does the actual
execution on the server side.
getActionType() returns the concrete Action subclass that the handler
supports. For example, a 'Get User' operation might look like this:
public class GetUser implements ActionGetUserResult {
private String name;
// For serialization
GetUser() {}
public GetUser( String name ) {
this.name = name;
}
public String getName() {
return name;
}
}
public class GetUserResult implements Result {
private User user;
// Serialization
GetUserResult() {}
public GetUserResult( User user ) {
this.user = user;
}
public User getUser() {
return user;
}
}
// This class is server-side only
public GetUserHandler implements ActionHandlerGetUser, GetUserResult
{
private final UserDAO dao;
@Inject
public GetUserHandler( UserDAO dao ) {
this.dao = dao;
}
public ClassGetUser getActionType() {
return GetUser.class;
}
public GetUserResult execute( GetUser action ) throws Exception {
return new GetUserResult( dao.getUser( action.getName() ) );
}
}
A very simple example, and the actual 'getting' code is wrapped in the
DAO in this case. It could equally be coded directly in, or hooking up
to a non-DB service. Depends how you want to implement it.
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Hi,
I have been playing a while, and I like Dave Peterson's, even with
that class proliferation, I wrote a simple (and incomplete) example
code:
http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pattern-on-server.html
Thanks
On 4 jul, 15:49, David Peterson da...@randombits.org wrote:
Jason: I'll admit I was unable to figure out exactly what Shindig's
approach is, exactly, unfortunately. However there is definitely more
than one way to skin this cat. My current implementation an Action, a
Result and a Handler for each operation. This does result in some
class proliferation, but has the upside of having everything nicely
self-contained.
In my implementation, I actually have a 'Dispatch' class which can be
injected directly, and a separate DispatchServiceServlet which is also
injected the same Dispatch instance and provides access from GWT/RPC.
To hold you over while I get the code sorted, here is a simple example
of what an action/result/handler looks like:
It's just a concrete implementation of ActionHandler. Essentially,
each Action/Result has a single ActionHandler that does the actual
execution on the server side.
getActionType() returns the concrete Action subclass that the handler
supports. For example, a 'Get User' operation might look like this:
public class GetUser implements ActionGetUserResult {
private String name;
// For serialization
GetUser() {}
public GetUser( String name ) {
this.name = name;
}
public String getName() {
return name;
}
}
public class GetUserResult implements Result {
private User user;
// Serialization
GetUserResult() {}
public GetUserResult( User user ) {
this.user = user;
}
public User getUser() {
return user;
}
}
// This class is server-side only
public GetUserHandler implements ActionHandlerGetUser, GetUserResult
{
private final UserDAO dao;
@Inject
public GetUserHandler( UserDAO dao ) {
this.dao = dao;
}
public ClassGetUser getActionType() {
return GetUser.class;
}
public GetUserResult execute( GetUser action ) throws Exception {
return new GetUserResult( dao.getUser( action.getName() ) );
}
}
A very simple example, and the actual 'getting' code is wrapped in the
DAO in this case. It could equally be coded directly in, or hooking up
to a non-DB service. Depends how you want to implement it.
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
I updated my project to only use the two interfaces as suggested by
David. Instead of using actionhandlers and registering them, I created
an annotation for the IRemoteProcedureCall implementations that
contains the canonical class name of the IProcedure that is to be run
on the server.
I'm very open to suggestions. Let me know what you think :)
http://code.google.com/p/gwt-command-pattern/
On Jul 4, 8:17 am, Herme Garcia hgar...@peoplecall.com wrote:
Hi,
I have been playing a while, and I like Dave Peterson's, even with
that class proliferation, I wrote a simple (and incomplete) example
code:
http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat...
Thanks
On 4 jul, 15:49, David Peterson da...@randombits.org wrote:
Jason: I'll admit I was unable to figure out exactly what Shindig's
approach is, exactly, unfortunately. However there is definitely more
than one way to skin this cat. My current implementation an Action, a
Result and a Handler for each operation. This does result in some
class proliferation, but has the upside of having everything nicely
self-contained.
In my implementation, I actually have a 'Dispatch' class which can be
injected directly, and a separate DispatchServiceServlet which is also
injected the same Dispatch instance and provides access from GWT/RPC.
To hold you over while I get the code sorted, here is a simple example
of what an action/result/handler looks like:
It's just a concrete implementation of ActionHandler. Essentially,
each Action/Result has a single ActionHandler that does the actual
execution on the server side.
getActionType() returns the concrete Action subclass that the handler
supports. For example, a 'Get User' operation might look like this:
public class GetUser implements ActionGetUserResult {
private String name;
// For serialization
GetUser() {}
public GetUser( String name ) {
this.name = name;
}
public String getName() {
return name;
}
}
public class GetUserResult implements Result {
private User user;
// Serialization
GetUserResult() {}
public GetUserResult( User user ) {
this.user = user;
}
public User getUser() {
return user;
}
}
// This class is server-side only
public GetUserHandler implements ActionHandlerGetUser, GetUserResult
{
private final UserDAO dao;
@Inject
public GetUserHandler( UserDAO dao ) {
this.dao = dao;
}
public ClassGetUser getActionType() {
return GetUser.class;
}
public GetUserResult execute( GetUser action ) throws Exception {
return new GetUserResult( dao.getUser( action.getName() ) );
}
}
A very simple example, and the actual 'getting' code is wrapped in the
DAO in this case. It could equally be coded directly in, or hooking up
to a non-DB service. Depends how you want to implement it.
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Hi all, I extracted the command-related code from my current project and have posted it here: http://code.google.com/p/gwt-dispatch/ The original code was working fine, but I haven't had a chance to test it since it was extracted from the project. It does compile, although you will currently need Java 1.6 to compile it (even though it is compiling in 1.5 class/source compatibility mode). There is only one section of generics-related code that requires 1.6 (you'll figure it out quickly if you check it out and build with 1.5), so if anyone can provide a patch I'll be happy to slap it in. There is also a short example on how to build an action/result/handler and wire it in via Guice/GIN. That can be had here: http://code.google.com/p/gwt-dispatch/wiki/GettingStarted I'll be hooking this library into my current project next week, so expect to see some minor adjustments and bug fixes, but it should be fairly stable. Enjoy! David Peterson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Can someone explain how this is useful? I don't know what a command pattern is. Why should I use command patterns and not the traditional way? What is the difference? At first look, this seems to be a lot more complicated, so I'm a little confused. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
For general information and benefits of the Command Pattern, see this article: http://en.wikipedia.org/wiki/Command_pattern GWT has some additional quirks that would make an abstracted command pattern nice, but I can see how you could say the added complexity might detract from those benefits. On Jul 4, 2:18 pm, martinhansen martin.hanse...@googlemail.com wrote: Can someone explain how this is useful? I don't know what a command pattern is. Why should I use command patterns and not the traditional way? What is the difference? At first look, this seems to be a lot more complicated, so I'm a little confused. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Yeah, there is some added complexity, however I found myself basically implementing it in a much more ad-hoc fashion anyway, it's just that some operations required a 'token' object with multiple parameters, or returning another token with multiple return values, and some didn't. This way, it's more consistent, and there is the benefit of undo and more fine-grained testing. For this project it was an experiment as much as anything, but from the experience I generally think there are more benefits than downsides, even for server-side-only projects. It definitely fits well with the DI-style of configuration. Each to their own though - it really is mostly a matter of taste. David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
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 ActionHandlerA extends ActionR, R extends Result
{
public ClassA 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 the command pattern using 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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
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:
ListBindingActionHandler bindings = injector
.findBindingsByType( TypeLiteral.get
( ActionHandler.class ) );
for ( BindingActionHandler 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 ActionHandlerA extends ActionR, R extends Result
{
public ClassA 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
-~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
Just a couple of other comments on this general topic. 1. Yes, it's one-class-per RPC method. This is actually a good thing, since it lets you do item 2, which is: 2. You can add 'undo' to your actions. This is particularly handy if you build your Action classes using item 3: 3. You can have one action which executes multiple other items. This means you're using the command pattern on the server side too, not just from the client side. When you add them all together, most of your actual functionality is encapsulated in command/action classes. I use the same service implementation on the server side as the client side, so there is really just one shared service now (I call it 'Dispatch') rather than having various services for different application functions. But for me, the biggest win is 'undo' - it's essentially like having transactions for Java code, not just database code. Not quite as bullet-proof, since some actions can't actually be undone, but a big step in that direction. I will see if I can get the code abstracted enough from my app to post it publicly. David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
I thought I posted this last night, but I don't see it. Apologies if this is a dupe. I've tried to implement the command pattern using 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 Practices For 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
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 Practices For Architecting Your GWT App : http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkit... He suggests a command pattern implementation 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 -~--~~~~--~~--~--~---
