Brian, I think it should be made clear that GWT Modules are reuse packagings, just like Java classes, and don't even imply a runtime application architecture. The only reason for breaking code into Modules is to reuse it by inheritance rather than duplicating code.
Walden On Nov 4, 11:58 am, Brian <[EMAIL PROTECTED]> wrote: > Err, "size and speed were increased by keeping it in one app" should > have read, "size was decreased, speed was increased by keeping all the > modules in one app." > > On Nov 4, 11:56 am, Brian <[EMAIL PROTECTED]> wrote: > > > > > I wanted to do something similar to having a bunch of independent > > modules interacting on a page, but gave up, and stuck with the > > monolithic app. I think you really need to analyze if it's worth > > breaking up the app into modules and trying to work with all this glue > > you'll need. For instance, there's quite an overhead in size for just > > a hello,world gwt app. You'll be paying this overhead for each > > module. Also, once the monolitic app is cached by the browser, it's > > there until cleared, so there's basically no penalty for having the > > app on multiple pages, even if it's not used "that much" (ie, not all > > modules are visible). Also, you can break up your monolitic app so you > > only create the classes needed in the given state, so you don't eat up > > memory for modules you're not displaying, etc, etc. It just ended up > > not making sense to break up the app -- > > > What are the advantages to breaking the app into modules? Size? > > Speed? In my case, size and speed were increased by keeping it all in > > one app, and relying on browser caching. > > > On Nov 4, 9:50 am, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > > > On 4 nov, 13:11, walden <[EMAIL PROTECTED]> wrote: > > > > > Joe, > > > > > You don't need DOM events, per se. Use Observer Pattern. Your Login > > > > module doesn't need to know who's subscribed. It just needs to > > > > implement the Observable interface (register listeners, fire login > > > > state change events). Your other modules are in fact dependent upon > > > > Login. They need to know how to register listeners, receive events, > > > > recognize Login events, and then I would suggest you let them probe > > > > the Login module directly for login state. > > > > > If you look at how ChangeListener and SourcesChangeEvents work in GWT, > > > > there are all the elements of the Observer pattern you need, and you > > > > can copy that. > > > > Walden, he has and wants (and needs?) distinct *applications* (not > > > only distinct *modules*), Java-GWT is not an option here. > > > > @Joe: you'll have to implement such an observer/observable pattern in > > > pure JavaScript in your host page, and use JSNI in your applications > > > to register handlers/fire events.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
