Hi James, Thanks for the thoughtful reply, it helps me to just talk this through. I really like the idea of having a topmost runtime module and a topmost test scaffold module. Quick question: would you recommend 1 project per module so you end up with multiple projects? Is there an easy way to manage multiple modules inside a single project?
On Mar 21, 11:29 am, "jgr...@gmail.com" <jgr...@gmail.com> wrote: > Hi Lance, > > I suggest you build one module for each functional area, plus some > modules common across the application, with each module *not* having > an entry point. The functional area module would inherit from the > common modules, in essence treating them as libraries. Eventually, > you will have one module, inheriting from each of the functional area > modules, that will define the one entry point for the entire > application. (You might also consider having this module that > represents the application also not have an entry point, and then have > two modules that inherit from it that just have entry points. One of > these two modules would act as the runtime module; the other would > have extra bits for testing.) > > Cheers, > James > > On Mar 20, 6:47 pm, Lance Weber <weber.la...@gmail.com> wrote: > > > With the arrival of the new project structure in 1.6 I'm looking for > > recommendations/experiences on organizing complex applications > > containing several major functional areas. > > > For purposes of this discussion, I'm envisioning > > -Application A > > --Functional Area A1 > > --Functional Area A2 > > --Functional Area A3 > > > Assuming each functional area shares > 50% common entities, business > > logic and gui components, it isn't clear to me what approaches to > > organizing the codebase will scale with the eventual size of the > > application. Here are some of the options as I understand them: > > > 1) Monolith Option. One project with one module, possibly supporting > > multple entry points. > > > 2) One project, multiple modules. Maintain one project, but create > > multiple modules to organize common classes and functional areas. (How > > do you accomplish this in 1.6? It's not clear to me) > > > 3) Multiple projects, one module per project. Create one project for > > each module, resulting in a commons project and a project for each > > functional area. > > > Any thoughts/comments on this would be welcome... > > Advantages/Disadvantages? > > Options I'm missing? > > Good/Bad experiences with these approaches? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
