On Apr 23, 8:32 pm, Ben FS <ben.su...@gmail.com> wrote: > Let's try a concrete example. Feel free to specify something closer to > what you want. I think you want to have a bunch of applications, each > of which could run on its own, but you also want a "housing" > application that provides navigation, etc. and decides which sub- > applications to include in the UI. Yes?
Yes. > One way to do this: > 1. Make a core GWT module. It defines an "Application" abstract class > that inherits from GWT's Composite class. > 2. Make the "housing" GWT module. It provides the high-level UI with > navigation, etc. and placeholders for one or more Application > instances. > 3. Make additional GWT modules, each containing a concrete sub-class > of Application. These are your "sub-applications". They each define an > EntryPoint, useful for testing them on their own, but mainly you will > instantiate each Application as a UI component in the "housing" > application. Yes, that's exactly the model I want from a where-is-the-code- developed-and-how-is-it-organized perspective. The dilemma I'm still facing is: do I go with "loading option" 1 or 2, where the options are described in the page you referenced in your last post (http://code.google.com/webtoolkit/doc/1.6/ DevGuideOrganizingProjects.html#DevGuideModules): 1. Compile each module separately and include each module with a separate <script> tag in your HTML host page. 2. Create a top level module XML definition that includes all the modules you want to include. Compile the top level module to create a single set of JavaScript output. That page strongly recommends #2, but that implies that I would be sucking down what would amount to an entire ERP application into my browser, right? I mean, the Javascript to define what the finance application is would be downloaded by the browser in option 2, along with the Javascript for the housing application, and the Javascript for the order application, and the Javascript for the kitchen sink application and so on, even if the customer spent all his time in the finance application. To make it more concrete, option 2 would have me do this in Housing.gwt.xml: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 1.6.4// EN" "http://google-web-toolkit.googlecode.com/svn/tags/1.6.4/distro- source/core/src/gwt-module.dtd"> <module rename-to='housing'> <inherits name='com.google.gwt.user.User'/> <inherits name='com.google.gwt.user.theme.standard.Standard'/> <inherits name='org.superbiz.modules.Finance'/> <inherits name='org.superbiz.modules.Order'/> <inherits name='org.superbiz.modules.KitchenSink'/> <!-- and so on --> <entry-point class='org.superbiz.modules.housing.Housing'/> </module> ...and I'd invoke the GWT compiler to assemble one great big hairball of Javascript, which would be included, once, in the housing's HTML: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <link type="text/css" rel="stylesheet" href="Housing.css"> <title>Housing Application</title> <!-- let's go get all 37 sub applications...go brew a pot of coffee! --> <script type="text/javascript" language="javascript" src="housing/ housing.nocache.js"></script> </head> <body> <iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1' style="position:absolute;width:0;height:0;border:0"></iframe> </body> </html> 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. So if I'm doing my homework properly, it looks like option #1, despite not being recommended, is nevertheless my best option, even though, in the words of the GWT developers, "each module will contain redundant copies of GWT library code and could possibly conflict with each other during event handling". (Lastly, it looks like option #2 could become a valid choice for me again once http://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?) 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
