Re: Extend AsyncCallback or ServiceInterfaceProxyGenerator
Done! Just a side note and slightly off topic and I hope you forgive me but every time I have to do one of these large, multi file code changes in a Web application I break into a sweat. I can't even begin to count the number of times I thought I had captured all the places in my html, javascript and css files where I needed to make changes and only found during testing that I missed a lot. Refactoring traditional web apps is, well it's a nightmare to put it mildly. However, implementing this multi file change to my GWT project was nothing like that and in fact it was the total opposite. Eclipse Java refactoring support is really quite excellent and this really drove home the point of how convenient GWT makes Web development. So my thanks goes out to Google and all the GWT team members for creating and maintaining an awesome product. IMHO GWT isn't evolutionary, it is revolutionary. Jeff On Fri, Jan 14, 2011 at 5:23 PM, Jeff Schwartz jefftschwa...@gmail.comwrote: I made up my mind and did that hurt lol :). Even though extending ServiceInterfaceProxyGenerator is rather trivial it might be overkill for my initial needs which extending AsyncCallback can easily provide and I can alway extend ServiceInterfaceProxyGenerator at some later point anyway. So my AsyncCallback will not only handle common exceptions in onFailure but it will also allow me to eliminate having to override onFailure 99.99% of the time making the code much more concise and readable. Thanks, Jeff On Fri, Jan 14, 2011 at 3:48 PM, Jeff Schwartz jefftschwa...@gmail.comwrote: Hi David, So far I have 146 and I am no where even nearly having a fully implemented application. Eclipse's refactoring definitely would ease the pain if I go with extending AsyncCallback :) Regarding extending ServiceInterfaceProxyGenerator, I've looked at the code and it doesn't appear to be that big of a deal to implement the generator which just outputs strings. One drawback to it though is if the api changes but I guess the same thing can be said for extending AsyncCallback as well. Gee, I am still on the fence over which way to go. I gather from your feedback then that if it were your decision to make you'd go with AsyncCallback. Jeff On Fri, Jan 14, 2011 at 2:17 PM, David Chandler drfibona...@google.comwrote: Hi Jeff, You must have a LOT of AsyncCallbacks in order to make it worth the pain of modifying generator code :-) Extending AsyncCallback is the technique most people use and makes sense as it's clearly application code. Perhaps one of the Eclipse refactoring tools can ease the pain? /dmc On Fri, Jan 14, 2011 at 10:08 AM, Jeff Schwartz jefftschwa...@gmail.com wrote: I want to implement common error handling in all of my RPC onFailure methods. Excluding repeating the error handling code in every invocation I can either 1) extend AsyncCallback and use it in all my invocations or I can 2) extend ServiceInterfaceProxyGenerator and have it generate an implementation of AsyncCallback for me that would include my common error handling. As I already have a lot of RPC calls using the normal AsyncCallback so using option 1 would obviously require refactoring a lot of code. In contrast, were I to use option 2 there would be no refactoring required. Perhaps the solution seems obvious, which is to use option 2, but I am hoping that you can provide feedback on both of these options and perhaps illuminate any potential problems with either before I commit to one or the other. Thanks a lot for your feedback. -- *Jeff Schwartz* -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkit w: http://code.google.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- *Jeff Schwartz* -- *Jeff Schwartz* -- 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
Re: Extend AsyncCallback or ServiceInterfaceProxyGenerator
Hi Jeff, You must have a LOT of AsyncCallbacks in order to make it worth the pain of modifying generator code :-) Extending AsyncCallback is the technique most people use and makes sense as it's clearly application code. Perhaps one of the Eclipse refactoring tools can ease the pain? /dmc On Fri, Jan 14, 2011 at 10:08 AM, Jeff Schwartz jefftschwa...@gmail.comwrote: I want to implement common error handling in all of my RPC onFailure methods. Excluding repeating the error handling code in every invocation I can either 1) extend AsyncCallback and use it in all my invocations or I can 2) extend ServiceInterfaceProxyGenerator and have it generate an implementation of AsyncCallback for me that would include my common error handling. As I already have a lot of RPC calls using the normal AsyncCallback so using option 1 would obviously require refactoring a lot of code. In contrast, were I to use option 2 there would be no refactoring required. Perhaps the solution seems obvious, which is to use option 2, but I am hoping that you can provide feedback on both of these options and perhaps illuminate any potential problems with either before I commit to one or the other. Thanks a lot for your feedback. -- *Jeff Schwartz* -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkit w: http://code.google.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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: Extend AsyncCallback or ServiceInterfaceProxyGenerator
Hi David, So far I have 146 and I am no where even nearly having a fully implemented application. Eclipse's refactoring definitely would ease the pain if I go with extending AsyncCallback :) Regarding extending ServiceInterfaceProxyGenerator, I've looked at the code and it doesn't appear to be that big of a deal to implement the generator which just outputs strings. One drawback to it though is if the api changes but I guess the same thing can be said for extending AsyncCallback as well. Gee, I am still on the fence over which way to go. I gather from your feedback then that if it were your decision to make you'd go with AsyncCallback. Jeff On Fri, Jan 14, 2011 at 2:17 PM, David Chandler drfibona...@google.comwrote: Hi Jeff, You must have a LOT of AsyncCallbacks in order to make it worth the pain of modifying generator code :-) Extending AsyncCallback is the technique most people use and makes sense as it's clearly application code. Perhaps one of the Eclipse refactoring tools can ease the pain? /dmc On Fri, Jan 14, 2011 at 10:08 AM, Jeff Schwartz jefftschwa...@gmail.comwrote: I want to implement common error handling in all of my RPC onFailure methods. Excluding repeating the error handling code in every invocation I can either 1) extend AsyncCallback and use it in all my invocations or I can 2) extend ServiceInterfaceProxyGenerator and have it generate an implementation of AsyncCallback for me that would include my common error handling. As I already have a lot of RPC calls using the normal AsyncCallback so using option 1 would obviously require refactoring a lot of code. In contrast, were I to use option 2 there would be no refactoring required. Perhaps the solution seems obvious, which is to use option 2, but I am hoping that you can provide feedback on both of these options and perhaps illuminate any potential problems with either before I commit to one or the other. Thanks a lot for your feedback. -- *Jeff Schwartz* -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkit w: http://code.google.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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: Extend AsyncCallback or ServiceInterfaceProxyGenerator
I'd recommend simply extending the AsyncCallback. Its undoubtedly more work up front, but its also not a hack, which is a Good Thing. Its easy to understand, and future maintainers of the program will thank you for that. Also, karma will likely stab you in the eye if you don't. -Ben On Jan 14, 2:48 pm, Jeff Schwartz jefftschwa...@gmail.com wrote: Hi David, So far I have 146 and I am no where even nearly having a fully implemented application. Eclipse's refactoring definitely would ease the pain if I go with extending AsyncCallback :) Regarding extending ServiceInterfaceProxyGenerator, I've looked at the code and it doesn't appear to be that big of a deal to implement the generator which just outputs strings. One drawback to it though is if the api changes but I guess the same thing can be said for extending AsyncCallback as well. Gee, I am still on the fence over which way to go. I gather from your feedback then that if it were your decision to make you'd go with AsyncCallback. Jeff On Fri, Jan 14, 2011 at 2:17 PM, David Chandler drfibona...@google.comwrote: Hi Jeff, You must have a LOT of AsyncCallbacks in order to make it worth the pain of modifying generator code :-) Extending AsyncCallback is the technique most people use and makes sense as it's clearly application code. Perhaps one of the Eclipse refactoring tools can ease the pain? /dmc On Fri, Jan 14, 2011 at 10:08 AM, Jeff Schwartz jefftschwa...@gmail.comwrote: I want to implement common error handling in all of my RPC onFailure methods. Excluding repeating the error handling code in every invocation I can either 1) extend AsyncCallback and use it in all my invocations or I can 2) extend ServiceInterfaceProxyGenerator and have it generate an implementation of AsyncCallback for me that would include my common error handling. As I already have a lot of RPC calls using the normal AsyncCallback so using option 1 would obviously require refactoring a lot of code. In contrast, were I to use option 2 there would be no refactoring required. Perhaps the solution seems obvious, which is to use option 2, but I am hoping that you can provide feedback on both of these options and perhaps illuminate any potential problems with either before I commit to one or the other. Thanks a lot for your feedback. -- *Jeff Schwartz* -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkit w:http://code.google.com/ b:http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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: Extend AsyncCallback or ServiceInterfaceProxyGenerator
I made up my mind and did that hurt lol :). Even though extending ServiceInterfaceProxyGenerator is rather trivial it might be overkill for my initial needs which extending AsyncCallback can easily provide and I can alway extend ServiceInterfaceProxyGenerator at some later point anyway. So my AsyncCallback will not only handle common exceptions in onFailure but it will also allow me to eliminate having to override onFailure 99.99% of the time making the code much more concise and readable. Thanks, Jeff On Fri, Jan 14, 2011 at 3:48 PM, Jeff Schwartz jefftschwa...@gmail.comwrote: Hi David, So far I have 146 and I am no where even nearly having a fully implemented application. Eclipse's refactoring definitely would ease the pain if I go with extending AsyncCallback :) Regarding extending ServiceInterfaceProxyGenerator, I've looked at the code and it doesn't appear to be that big of a deal to implement the generator which just outputs strings. One drawback to it though is if the api changes but I guess the same thing can be said for extending AsyncCallback as well. Gee, I am still on the fence over which way to go. I gather from your feedback then that if it were your decision to make you'd go with AsyncCallback. Jeff On Fri, Jan 14, 2011 at 2:17 PM, David Chandler drfibona...@google.comwrote: Hi Jeff, You must have a LOT of AsyncCallbacks in order to make it worth the pain of modifying generator code :-) Extending AsyncCallback is the technique most people use and makes sense as it's clearly application code. Perhaps one of the Eclipse refactoring tools can ease the pain? /dmc On Fri, Jan 14, 2011 at 10:08 AM, Jeff Schwartz jefftschwa...@gmail.comwrote: I want to implement common error handling in all of my RPC onFailure methods. Excluding repeating the error handling code in every invocation I can either 1) extend AsyncCallback and use it in all my invocations or I can 2) extend ServiceInterfaceProxyGenerator and have it generate an implementation of AsyncCallback for me that would include my common error handling. As I already have a lot of RPC calls using the normal AsyncCallback so using option 1 would obviously require refactoring a lot of code. In contrast, were I to use option 2 there would be no refactoring required. Perhaps the solution seems obvious, which is to use option 2, but I am hoping that you can provide feedback on both of these options and perhaps illuminate any potential problems with either before I commit to one or the other. Thanks a lot for your feedback. -- *Jeff Schwartz* -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkit w: http://code.google.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- *Jeff Schwartz* -- 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: Extend AsyncCallback or ServiceInterfaceProxyGenerator
You must have been reading my mind because your reply arrived as soon as I posted my decision. I am a devout believer in Karma and as we know it is nothing to sneeze at; my luck, I'd get hit in the head by a 600 page hard covered book dedicated to DotNot web development falling from an elevated train station. Thanks, Ben. Jeff On Fri, Jan 14, 2011 at 5:20 PM, Ben Imp benlee...@gmail.com wrote: I'd recommend simply extending the AsyncCallback. Its undoubtedly more work up front, but its also not a hack, which is a Good Thing. Its easy to understand, and future maintainers of the program will thank you for that. Also, karma will likely stab you in the eye if you don't. -Ben On Jan 14, 2:48 pm, Jeff Schwartz jefftschwa...@gmail.com wrote: Hi David, So far I have 146 and I am no where even nearly having a fully implemented application. Eclipse's refactoring definitely would ease the pain if I go with extending AsyncCallback :) Regarding extending ServiceInterfaceProxyGenerator, I've looked at the code and it doesn't appear to be that big of a deal to implement the generator which just outputs strings. One drawback to it though is if the api changes but I guess the same thing can be said for extending AsyncCallback as well. Gee, I am still on the fence over which way to go. I gather from your feedback then that if it were your decision to make you'd go with AsyncCallback. Jeff On Fri, Jan 14, 2011 at 2:17 PM, David Chandler drfibona...@google.com wrote: Hi Jeff, You must have a LOT of AsyncCallbacks in order to make it worth the pain of modifying generator code :-) Extending AsyncCallback is the technique most people use and makes sense as it's clearly application code. Perhaps one of the Eclipse refactoring tools can ease the pain? /dmc On Fri, Jan 14, 2011 at 10:08 AM, Jeff Schwartz jefftschwa...@gmail.comwrote: I want to implement common error handling in all of my RPC onFailure methods. Excluding repeating the error handling code in every invocation I can either 1) extend AsyncCallback and use it in all my invocations or I can 2) extend ServiceInterfaceProxyGenerator and have it generate an implementation of AsyncCallback for me that would include my common error handling. As I already have a lot of RPC calls using the normal AsyncCallback so using option 1 would obviously require refactoring a lot of code. In contrast, were I to use option 2 there would be no refactoring required. Perhaps the solution seems obvious, which is to use option 2, but I am hoping that you can provide feedback on both of these options and perhaps illuminate any potential problems with either before I commit to one or the other. Thanks a lot for your feedback. -- *Jeff Schwartz* -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- David Chandler Developer Programs Engineer, Google Web Toolkit w:http://code.google.com/ b:http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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.
