On Apr 23, 1:04 pm, Jeff Chimene <jchim...@gmail.com> wrote: > You're asking two questions:
At least. :-D > 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.? Each of which would feature at least one entry point? How are you suggesting I should pull these entry points together under the "housing"? That's where I'm conceptually stuck. Or, conversely, given a housing .war, how should it pull content from other .wars? Now, I'm thick and slow at this stuff so far (early days!) but my understanding is that an entry point is Java-to-Javascript code that is executed when a host HTML page makes reference to the entry point. So if I have an HTML page that refers to 127 entry points, then it's like running 127 main() (onModuleLoad()) methods. 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. 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. Perhaps another way to ask (one of) my questions is like this: I want one .war to have the HTML files that are in charge of deciding what entry points--from various other .war files--to load. There are two problems with this, which is partly why I feel like I'm groping in the dark, and am reaching out to the GWT group here: 1. War files don't know about other war files. So war file 1 can't go rummaging around in war file 2 to find a GWT module. That's nevertheless sort of what I want to happen. 2. Since that really isn't an option, what's left is the housing referring to something like a list of URLs, each of which talks to a servlet or what-have-you hosted by the "housed" war files. That is, let the Housing GWT app load up in the browser and then kick off a bunch of async requests to go hit various URLs for the sub- applications. Something here just smells fishy to me; I am not articulate enough at the moment to be able to state clearly what my problem is with this approach. Perhaps you or someone else can educate me here. One ancillary thing that occurs to me is that security and authentication is a pain going this route unless there's an SSO server back there somewhere. > GWT gives you the ability to use Java source code management and > testing technology while generating Javascript. I'd leverage that going > forward. You haven't mentioned the server-side code. That may affect > this discussion. True; good point. For now, assume it's pure JEE 5 stuff (.war files, servlets, EJB3 on the back end). We haven't made a final decision on whether to use GWT RPC stuff or go pure web services for our communication with the back end. > o How to crush multiple legacy apps together, still keep them unique, > while leveraging HTML > Frames. Seriously? Yikes. These aren't legacy applications, BTW; they're being developed right now. 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 -~----------~----~----~----~------~----~------~--~---
