One implication that you'll have is the possible increase of compilation units in your applications. Since each of the host pages would show something different, you'd have one entry point for each. Since you don't want to download and start all of the entry points when you're only using one, you'll want them in separate modules. This will slow down GWT compilation because any code shared among the modules (including GWT itself and the JRE emulation layer) will be recompiled for each module.
For a new project, I'm not sure what you would gain be keeping these separate, other than having separate ".html" locations for each feature (which is a purely aesthetic decision as you can achieve persistent locations for each feature using GWT's history support, especially places in GWT 2.1). I faced a similar problem when trying to integrate GWT into a legacy application. I didn't want to replace the entire application frame (yet) but wanted to be able to implement certain pages using GWT. After manually implementing a solution involving a single dispatching entry point and a javascript variable token, I came across gwt-multipage (http://gwtmultipage.org/) which did something similar using a URL pattern. I contributed the javascript token switching logic to that project and am using it now. If you really need separate pages, that might be helpful for you. -Brian On Sat, Jan 1, 2011 at 8:29 PM, zixzigma <zixzi...@gmail.com> wrote: > Hello Everyone, > > normally GWT apps are consisted of only one HTML page. > this html page loads one or more scripts. > User navigation is through manipulating the history tokens/Places. > > what if someone decided to implement the approach below: > > instead of having only one HTML page for entire application, > have one HTML page per functional area (workspace/section). > > for example, if an application has > > Employee Management section , > Document Management section, > AccountSettings section, > Message/Notification section, > > what if, these four different part of the application, > were in fact in four separate HTML files. > > and navigating from one section to other, > was done in traditional sense. > > each section, in its own page, > showing widgets/interacting with user, > loading data/ etc .... > basically an independent application on its own > and once user decides to navigate away to different part of > an application, it is basically a different gwt .html page. > > to summarize, partitioning our big application > into semi-autonomous sections, with their own .html file. > and linking these sections through "<a href=" "> > > after all, these gwt main html files, are basically empty, > just loading a script, so it is not like we are loading a heavyweight > html page. > > what is wrong with this design ? > what are the implications ? > > -- > 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-tool...@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. > > -- 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-tool...@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.
