> > I guess I should probably have a single module and top level entry > point and then switch between interfaces from there but that will > involve a lot of code refactoring. >
It doesn't need a lot of refactoring, it can be done on an incremental basis. I am assuming have 3 entry point classes corresponding to 3 modules, each of which is included in a separate HTML host page. Each module is a separate workflow. [The exact number doesn't matter]. - Get rid of all the modules(workflow A, through C), but keep the java classes implementing EntryPoint as-is. - Next, create a new module, say we call it parent-workflow. - In the onModuleLoad() of parent-workflow, figure out which workflow (A, B or C) to load, and then just delegate to the onModuleLoad() of the appropriate child workflow. [Of course, it doesn't have to be onModuleLoad() - but we are reusing it because of the high refactoring cost]. How do you figure out which child workflow to load? Append a fragment identifier to the URLs (#workflowA), and use History.getToken() to make the decision in the onModuleLoad() method of the new If your original urls were like this - http://mydomain.com/workflowA.html, http://mydomain.com/workflowB.html, http://mydomain.com/workflowC.html they will now become - http://mydomain.com/parent-workflow.html#workflowA, http://mydomain.com/parent-workflow.html#workflowB, http://mydomain.com/parent-workflow.html#workflowC This way, control will always go to the single, top-level module, and from there you decide which workflow to load. Plus, it gives you history management and back button support. Notice that you have got rid of 3 HTML files, 3 *.gwt.xml files, and in due course - 3 EntryPoint classes. And since there is only one entry point, your compilation is a lot faster, it is easier to share common widgets, and you get more optimized javascript code. This is the least intrusive way to get to a single module. With time, you can figure out different strategies to map the history token to the appropriate workflow. You can also refactor your code to get rid of the additional EntryPoint classes, and come up with your own interface to define a workflow (or screen or page or whatever you want to call it). Once you get a hang of the basic idea, read the MVP pattern. Go through Ray Ryans presentation. That will give you more ammunition to better design your application. --Sri 2009/11/14 rolf <[email protected]> > What's the best way to create a web app with multiple entry points but > a lot of common code (eg. common widgets and dialogs) shared between > them, as well as a common server back end? Currently I'm creating > multiple modules and multiple HTML pages within a single web app but > I'm also worried about scalability. The different entry points > correspond to different workflows depending on what the user is trying > to do, or perhaps customised versions of the interface for particular > customers. > > I guess I should probably have a single module and top level entry > point and then switch between interfaces from there but that will > involve a lot of code refactoring. > > -Rolf > > On Nov 14, 11:50 am, Sripathi Krishnan <[email protected]> > wrote: > > Multiple modules is the wrong way to use GWT. > > > > GWT highly recommends using a single module. Most of the performance > > optimizations GWT does relies on the fact that you have a single, > monolithic > > module. Plus, as you observed, the time to build your application keeps > > growing as you add more modules, so it doesn't scale well. > > > > Part of the problem is deciding whether you are building a "Web App" or a > > "Web Site". Lots of > > discussions< > http://www.clyral.com/za/pages/web/website_vs_webapplication.html>can > > be found on this topic. > > > > GWT is great if you want to build a Web App. Typically, there is only a > > single HTML page, and different "screens" are manipulated on the client > side > > using DOM. But if you are building a traditional, multi-page Web Site > > (nothing wrong with that), then GWT is not for you. You are better off > using > > one of the many javascript libraries. > > > > So, lets assume you decide you want to build a web-app, and want to use > GWT > > to do so. To get started, stick to a single HTML page with a single GWT > > Module/Entry Point. Adding multiple "screens" is adding a new FlowPanel > or > > Composite with your content. Or perhaps, you have all "screens" built > into > > the original HTML page, and you just hide/unhide the divs based on user > > action. > > > > The above approach works well if you have a few (say less than 10) > screens. > > If your application grows bigger and more complex, you would want to > start > > following some established patterns. The MVP pattern has been touted as > the > > "way to build web-apps". Just do a google search, there are a lot of > > articles on that subject. Also, catch Ray Ryan's talk on GWT Architecture > > and best practices< > http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPr...>. > > > > --Sri > > > > 2009/11/13 David C. Hicks <[email protected]> > > > > > > > > > Specifically, I'm curious about the use of GWT Modules in a project. > > > > > Each time we have a new "screen" to create, we have been adding a new > > > module to our project. Of course, with each new module, there is an > > > additional build cycle to generate the Javascript for that module. > What > > > I'm wondering is if this is normal, or does it make more sense to try > to > > > build up whole applications in a single module and perhaps keep the > > > build time down? Each new module we add appears to increase our build > > > time by about 1.5 minutes. It won't be long and this will be way > beyond > > > painful. > > > > > Any thoughts? > > > Thanks, > > > Dave > > > > > -- > > > > > 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]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=. > > -- > > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=. > > > -- 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=.
