Thats typically the way I deal with things, it allows you to isolate eat "action" that occurs against the server.
It also allows those actions to be developed against client side interfaces. One of the more common use cases I have is "Page" structures. Any list / table / scrollable view that needs to lazy load lots of data runs through the same "FetchPage" action (which encapsulates the fetch from an Async interface and the push into a PagedModel object when the response is returned). Another could be a SaveAction that stores an object on the server and validates that it was stored in the response. This is the main reason I favor working with top-level classes: it lets you code a step away from your actual work-structure (and so improve code re-usability). Hope that helps. //J Bakul wrote: > Jason, > > Does it mean I need to create a Action class for all kind of a backend > call? > > I mean, suppose I have three function call to back end from Async > Interface: > > 1. addItem(..., AsyncCallBack<T> callBack); > 2. updateItem(..., AsyncCallBack<T> callBack); > 3. deleteItem(..., AsyncCallBack<T> callBack); > > In this case, do I need to create three Aciton classes which extends > RetryAction? > > -Bakul > > > On Aug 23, 9:08 am, Jason Morris <[email protected]> wrote: >> I would personally say that creating top-level or inner classes for the >> response of an async >> callback (or an event) is often the best way to do it. >> >> Encapsulation is one of the main reasons we use OO languages because it >> encourages re-use. If you >> take a look at my blog post >> here:http://lemnik.wordpress.com/2008/07/17/a-useful-gwt-rpc-pattern-ive-b... >> You'll see one of the ways in which you can leverage encapsulate logic to >> make your code more >> friendly. Make the RetryAction a Command object and you'll really start to >> see what I mean. >> >> I mostly find that in the long run it works better to avoid inline >> callbacks, since it provides >> better separation of concerns, and acts more like the Command pattern (and >> you can mix in a Command >> Processor to produce more complex logic). >> >> Just my 2c worth. >> Regards. >> //Jason >> >> >> >> jack wrote: >>> Good question - lol. >>> I think maybe we're not quite using the same terminology - maybe we >>> are. >>> By inner class I mean something like ... >>> public MyOuterClass >>> { >>> } >>> On Aug 23, 1:34 am, Jan Ehrhardt <[email protected]> wrote: >>>> It's common practice to use inner classes in Java for listeners or other >>>> simple things like callbacks. >>>> What you want to do in the case of a callback, is invoking a method after >>>> the the asynchronous RPC has been finished. The easiest solution would be, >>>> to put this method as an argument to the RPC method, but since Java has no >>>> closures, using inner classes is a nice solution. In Java 1.4, where no >>>> inner classes where available, people implemented the AsyncCallback >>>> interface in the class, which was calling the RPC method, so they could do >>>> something like: >>>> service.getSomthing(this); >>>> But with Java 5 inner classes have become the prefered way. >>>> Sure, you can also create your own class for this, but that's the worse >>>> practice, I think. >>>> What would be the best solution for this, you think? >>>> Regards >>>> Jan Ehrhardt >>>> On Sat, Aug 22, 2009 at 10:43 PM, jack <[email protected]> wrote: >>>>> In every RPC example I've seen, AsyncCallback are all defined inline? >>>>> Why is this so? What are the advantages? >>>>> Thanks in advance > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
