mugle-dev team mailing list archive

[Matt Giuca <matt.giuca@xxxxxxxxx>]

   - GWT is going to try very hard to make us have just a single HTML page.
   We should go with the flow rather than fight it. (Yes, it seems weird to
   everyone, but see http://twitter.com)
      - There is a blog post explaining this weird architecture:
      http://alensiljak.blogspot.com/2009/04/gwt-concepts-no-multiple-pages.htmlSome
select quotes:
      - "As others have pointed out, the Right(TM) way to do this is using
      the History mechanism."
      - "First, you should think of your GWT app as a single *HTML* *page*,
      in which user and application events cause PORTIONS of the *page* (ie
      DOM elements) to change, be replaced, or loaded with content
from the server
      or internal application logic. In general you will not be sending the
      user/browser to another "real" URL. Your initial *HTML* *page* is
      basically a canvas on which your GWT application spews up content in
      response to user or server events (the typical AJAX model)."
      - "Finally, you typically will only have one
*EntryPoint*implementation with an onModuleLoad method in your
application. ... It might
      be helpful to think of your *EntryPoint*.onModuleLoad() as if it were
      simply the main() method of a more traditional application."
      - So my advice on this would be to treat GWT as if it were a
      traditional desktop application, which connects to network services via
      HTTP. Somewhat like a standalone Twitter client -- it's just one "window"
      with lots going on inside it, and all the network traffic comes from
      clicking buttons which sends HTTP requests to the server. But
only the Ajax
      requests are HTTP requests; all of the client-side logic is
loaded into one
      giant page when the application loads.
      - Our individual student projects will be an exception to this;
      they'll run in separate GWT canvases.
      - Services are extending other services to use their methods. e.g.,
   AdminService extends DeveloperService and AdminServiceImpl extends
   DeveloperServiceImpl.
      - Firstly, does AdminService need to extend DeveloperService? I
      thought it would be fine if just the impls inherit.
      - Secondly, why is this done at all? Is it just so that AdminService
      can use the methods of DeveloperService, on the server side? If so,
      AdminServiceImpl should instantiate a DeveloperServiceImpl
instance and use
      it there, rather than (ab)using inheritance.