I was thinking about this a little more, and threw around a couple ideas where "it would be nice" to break a monolithic-at-runtime application into runtime modules (analagous to breaking an .exe into a bunch of .dll's).
How much javascript can a browser deal with? If there's some maximum size an application can reach before a browser has problems using it, it'd be nice to break the application into runtime chunks and bring them in as needed. Administration screens -- I don't bundle admin functionality into an app, but it would be nice, based on user permissions, to just add the Admin panel to the application. Instead, it's a whole separate app (not that big of a deal, really). Anyway, although I said just make a monolithic application as I believe it's the right thing most of the time, not knowing if there's an application size upper-limit size makes me wonder. On Nov 4, 3:30 pm, walden <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
