I'm thinking about creating one AsyncCallback with a eventId field which is a constant coming from an enum, and up to the eventId, do different actions onSuccess method ...
like : service.makeRPC(arguments, new MyAsyncCallback(MyEvents.SEARCHBUTTON)); and the MyAsyncCallback will be like, public class MyAsyncCallback implements AsyncCallback { private int eventId = 0; MyAsyncCallback(int eventId) { this.eventId = eventId; } .... public void onSuccess(Object o ) { if(eventId == MyEvents.SEARCHBUTTON ) { // todo } else if ( .. ) { // todo } } } What do you think it will increase some kind performance ? On Oct 28, 8:49 am, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > On Mon, Oct 27, 2008 at 7:16 PM, trancemar <[EMAIL PROTECTED]> wrote: > > Which pattern do you recommend to not create an AsyncCallback class > > for each RPC ? > > I basically always use an anonymous local class, like this: > > service.makeRPC(arguments, new AsyncCallback<ResultType>() { > > public void onFailure(Throwable caught) { > // I don't have a coherent error-handling policy yet, so I still just do > Window.alert("In makeRPC onFailure: " + caught.getMessage()); > } > > public void onSuccess(ResultType result) { > // I almost always delegate to a method somewhere in the enclosing type > setResultTypeInstance(result); > } > > }); > > It feels like inline code to me, and, as a result, I don't feel any > "cognitive weight" with this approach. Are you creating separate > .java files for your AsyncCallback subtypes? > > Ian --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---