Hi Laird, see below. > I appreciate the efficiency of this from a DRY standpoint--the GWT > internals are downloaded once--but I don't appreciate the > *in*efficiency of this from a load-the-whole-world perspective. That > is, I don't particularly want 27 sub-apps living in my browser unless > they are absolutely needed; I'd rather only reference an HTML page > that does a <script src=""> import when that portion of the overall > app is needed.
Above you said 37, here you say 27 sub-apps, I assume neither number is real. But I think a more important estimate is how many different configurations of these sub-apps do you envision? You mentioned two options, but I think there is a third option, and I think it might work better for you. But it depends on how many different configurations of your sub-apps are to be expected. Option #3: You have many (ca. 30?) sub-apps. These will be combined in various ways depending on user needs. How many such configurations are there? Let's assume there are five. I suggest you take your "option 2" approach but apply it to each of these five configurations, rather than the single monolithic approach. a. So if you had 30 sub-apps, you'd have 30 sub-app modules (each inherits from "Application"). b. You'd still have the "housing" module, to maintain a common feel (it houses multiple "Application" instances). c. If you had 5 required configurations, you'd have 5 more modules. Each of these modules instantiates a Housing instance, instantiates the necessary Application instances, and adds these to the Housing. You'd probably define a "Configuration" class. I think this will give you the benefit of delivering to your users only just what they need, without duplication and without extraneous sub-apps. > (Lastly, it looks like option #2 could become a valid choice for me > again oncehttp://code.google.com/p/google-web-toolkit/wiki/CodeSplitting > goes in to an official release. That is, it looks like code splitting > will allow me to compile a giant GWT module--consisting of the finance > app, the order app, the housing app, the kitchen sink app--but > deferring much of the loading of hunks of the Javascript until they're > actually needed. Should I begin designing assuming that code > splitting will appear soon, or is that a mechanism that is not > designed to be used in such ordinary business-application ways?) No idea on the timing. My suggestion would be to go with my "option 3" for now and, as dynamic code slurping becomes available I think you should have a pretty smooth transition. This announcement says it will be post-1.6 but that's all I've seen: http://googlewebtoolkit.blogspot.com/2008/12/whats-ahead-for-google-web-toolkit_10.html > > Thanks again for your time. > > Best, > Laird --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
