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 [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
-~----------~----~----~----~------~----~------~--~---
