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 <[email protected]>wrote: > 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 <[email protected]>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 >> <[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* >> >> > > > -- > *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 [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.
