Hi Trancemar,
I agree with Magno that using a single global callback would make code
unreadable spaghetti (artificial disconnection between requesting
section of UI and response callback), and with Lothar that it would
be, if anything, slower since you'd have to slog through the entire if-
else/switch structure for every response.
Looking at your example, there is a way to rationalize your RPC calls/
callbacks somewhat using what one might call a "CommandDTO" or
"SuperDTO" as the RPC call parameter and it's return value. Let's say
you have some component that makes RPC calls, and these calls vary
depending on values set or actions performed within that component
(e.g. a specific button clicked or check box ticked). You can create a
"CommandDTO" class that encapsulates both client request options and
possible server responses used by the component. It might contain any
or all of:
- Command instructions that control RPC servlet execution logic (e.g.
your MyEvent enums)
- Objects that might need to be passed to the RPC servlet as
parameters
- Command instructions from the server (including possibly exceptions)
the client will need on return
- Data objects returned to client by the RPC servlet
- An onResponse() method that uses server instructions and return
values to control/fire updating the component's state.
In this scenario your component has one RPC call with one callback,
and the CommandDTO is both the (single) parameter of the RPC call and
the return value picked up in onSuccess(). Your single onSuccess()
then simply calls myCommandDTO.onResponse(). I think this can be
useful in certain situations, particularly where a component would
otherwise have to make use of many separate RPC method calls (and
their attendant callbacks) to cater for variations or chain multiple
RPC calls together to cater for step logic. In other words it can (but
not always) simplify RPC management at the component level.
However I would not do this globally at the application level (i.e.
have a single such RPC service used by all components) for the reason
Magno states. Basically because asynchronous logic can be messy enough
anyway and disconnecting it from where it's most needed (the calling
component) just makes it worse, and also because to do so implies a bi-
directional relationship between components and this central RPC
system, and IMO bi-directional relationships are best avoided if
possible.
regards
gregor
On Oct 28, 9:33 am, Lothar Kimmeringer <[EMAIL PROTECTED]> wrote:
> trancemar schrieb:
>
> > public void onSuccess(Object o ) {
> > if(eventId == MyEvents.SEARCHBUTTON ) {
> > // todo
> > } else if ( .. ) {
> > // todo
> > }
>
> > }
>
> The application I'm currently working on has a count of 187 AsyncCall-
> back-classes being used as callback of RPC-functions[1]. So alone the if-
> elsif-cascade would take nearly 400 lines inside the onSuccess-method
> (and the onFailure-method as well, because I print localized
> error-messages as well).
>
> > What do you think it will increase some kind performance ?
>
> Check it out. Write a GUI, that does repeated calls using callbacks
> the regular way and your way and compare the result. But I doubt
> that there will be significant differences, especially because we're
> talking about something that involves a complete HTTP-request-
> response-roundtrip that should way more time than the simple
> creation of an instance of a class (assuming that this still happens
> inside the Javascript-code being generated by the GWT-compiler).
>
> Regards, Lothar
>
> [1] I used a
> find -name '*.java' -print0 | xargs -0 grep -c "new AsyncCall"
> to find out.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
