On 04/23/2009 01:22 PM, Laird Nelson wrote: > On Thu, Apr 23, 2009 at 3:49 PM, Jeff Chimene <jchim...@gmail.com > <mailto:jchim...@gmail.com>> wrote: > > On 04/23/2009 10:39 AM, Laird Nelson wrote: > > On Apr 23, 1:04�pm, Jeff Chimene<jchim...@gmail.com > <mailto:jchim...@gmail.com>> wrote: > >> � � �You've already said you don't want to "... have one giant > .war file > >> that represents my whole application...". In GWT, I'd use multiple > >> applications, each with its own entry point. Apply generous > amounts of > >> JUnit. > > > > So--just so I'm clear--five .war files, five Eclipse projects, etc.? > > If you don't want a monolithic .war, you'll have (WAR count) > 1, no? > > > That's certainly what I thought, but I wasn't sure if it was possible > to, for example, split out the "housed" applications into jar files > and then glom them all into a war file at war file construction time. > > Forget Eclipse projects for the moment. It's a question I didn't ask > (what IDE are you considering?), and deliberately so. > .war files are IDE independent. Using Maven, you can construct > .wars in > whatever way suits your deployment strategy. > > > Yes, and that's actually what we're using. Well, or looking to use > anyhow. > > Remember, .war files are a Java construct shoe-horned into a > Javascript > world. They solve a large-ish problem while (perhaps) creating others. > On a server, one doesn't "pull content from other .wars". The content > will be served via your httpd from a directory containing Javascript, > HTML, images, &c. My apologies if you already know this. > > > I do, but no need to apologize. > > Perhaps NetBeans is appropriate here? Please read on for further > questions on that point. > > > NetBeans is a Swing-based rich client framework; I think perhaps you > have it confused with something else? > > > So if I want the > > housing app to pull in the, say, finance application, then somewhere > > under the control of the housing app there will be an HTML page > > sucking in the housing module/entry point, and sucking in the > finance > > module/entry point. > > Entry points are one thing. Libraries of application-specific code are > also possible (implemented via Java classes). > > > Right. > > > Now in a perfect world I wouldn't want the housing app to know that > > it's pulling in the finance app. I come from a rich client > > development background, primarily, doing stuff on the NetBeans > > platform. There you can drop your NetBeans modules (.jar files) in > > The Right Place, and the "housing" (the NetBeans platform) picks > them > > up dynamically and runs them. I'm looking for the GWT analog here. > > I'm probably not a good reference for NetBeans. NetBeans is an > architecture that embraces Javascript and HTML, no? > > > No. :-) No problem.
I was thinking of the "NetBeans IDE Bundle for Web & Java EE". If one can send HTML to the client, one can send Javascript. GWT is designed to fit nicely into such environments. > > I think the "GWT analog" is: > o The client makes AJAX requests of the server; > o The server, running in a NetBeans framework, decides which of > several > resources can respond to the request; > o Those resources, in the form of raw data, Javascript, HTML, > images, &c > are sent to the client; > o The response is transformed using the GWT classes into (D)HTML and > other UI shiny stuff > > > The reason I'm hung up on the implementation is not because I haven't > thought about how the application should behave. If anything, I've > thought TOO hard about that, as well as how the applications, plural, > should be maintained, developed, versioned, upgraded, customized, and > finally aggregated together into different wholes for different > clients. One client, for example, may want the finance application > only. Another may want the order application and the finance > application. Both clients will of necessity need the "housing", since > that governs how you navigate around this sick little world. ;-) It sounds like you have a /lot/ of Java coding/maintenance/deployment experience. Don't be throwin' that away. Did you check out the scribd link? One of GWT's design goals is to provide you the leverage you need to make use of those Java/team management skills. > So it's really more of a packaging question I'm asking than a Help Me > To Understand GWT question--the only reason GWT comes into play that I > can see is that it appears that GWT is not capable of modularly and > dynamically sucking in *code* at runtime that didn't exist before. > See, for example, this excellent thread: http://tinyurl.com/cveeft. Yes, but (/me wields a thread): http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting > (Returning briefly to NetBeans for a moment, the whole architecture is > built on the fact that it sucks in code dynamically at run time. So > the NetBeans "housing" fires up empty, initially, and then scans the > classpath or other area to discover the various little-m modules it > needs to pull in, and does so. In GWT's case you have to specify > those modules up front, i.e. in your HTML host page. If the HTML host > page is being served out of a location or package or .war file or > other kind of web application hairball that is supposed to be > self-contained, by definition it can't know about other .war files or > packages or locations or web application hairballs that contain the > code that should be dynamically loaded.) Not all modules have to be specified up front. That's where CodeSplitting (ibid) and other DHTML tricks are appropriate. > > It's not clear to me how much client-side Javascript you'll need. From > the outside, it seems that most business logic will be on the server, > the only use for the client is to manage the UI. > > > Yes; that is very much true. > > I think that your client side code will be quite thin; > authenticate/authorize the user, then dispatch to appropriate entry > point. > > > So good, you're starting to get closer towards my conceptual > troubles. Let's pretend just for the sake of argument that each of > these applications I'm talking about lives on a separate > server--forget their packaging technology (.war, directoreis, > whatever). They don't, but the boundaries make my misunderstandings a > little easier to articulate. > > So the housing application (on server H) serves up a simple HTML page > that contains a form to authenticate the user. I submit the form. > Server H receives the submission, authenticates me against something, > and sends me back an HTML page that bootstraps up the housing entry point. > > That part is brain dead simple and easy. The housing entry point is > also on server H, and is something that of course it should know about > directly, because, hey, it's part of the "housing" application. > (Constrast this to the finance application, for example, which you > know and I know exists over there on server F, but the housing > application doesn't (and shouldn't) know that.) To the point that "... and is something that of course it should know about directly ..." What about an MVC framework that neatly sidesteps this "... know about directly..." requirement? I think you're alluding to this when you offer the finance application example. I'm not sure why the housing app. is in a privileged position on the client side w/r/t the financial app. Does REST (http://en.wikipedia.org/wiki/Representational_State_Transfer) offer any guidance here? > Back to our stupid scenario. Various shiny widgets and trees and UI > goodness ensue, all of which are contained by and offered up by the > housing application on server H. > > Now suppose in the "content area" of this mythic application I would > like the finance application to magically appear. It is, let's say, > contained by and offered up by server F, and I certainly don't want to > edit anything in the housing app (other than configuration data) to > couple it tightly to the finance app. > > So clearly I don't want my housing entry point/module to know anything > about the finance application directly, but I *do* want my finance app > to appear in the context of my housing app. > > The way that I've thought of to do this, about which I have no sense > of its propriety, is to have the *server side* of the housing > application dynamically generate the HTML page that launches the > housing app's entry point, so that it would contain <script> tags > pointing off to the finance app. "Pointing off to" means of course > referencing a full URL to the nocache.js file hosted, in this stupid > example, on server F. It's not necessarily the nocache file. In fact (and you may be required to because of Same Origin Policy constraints), you might load the Finance app via JSON (retrieved via an AJAX call) and execute() the returned data. To repeat, that's a problem that CodeSplitting (ibid.) is designed to solve. > Thanks for your time and help; I greatly appreciate it. You're welcome. I hope that the GWT list can help. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
