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 <[email protected]>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 > <[email protected]>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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> > > > > -- > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- *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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
