Sounds interesting, thanks for the head's up.
On Nov 4, 5:30 pm, "Isaac Truett" <[EMAIL PROTECTED]> wrote: > Brian, > > It sounds to me like the scenarios you describe here would be > addressed by the runAsync work currently underway. The runAsync > feature will allow the developer to indicate portions of code that can > be lazily loaded from the server as needed. The compiler takes care of > separating and ensuring that things get loaded in the proper order. > You can learn more about it by searching the contributor's forum. > > - Isaac > > On Tue, Nov 4, 2008 at 5:24 PM, Brian <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
