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.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.com<google-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<google-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.
