By module inheriting I meant <inherits ...> in the config of the main application as well as you mentioned the places where the app makes calls to this submodules directly.
Thanx a lot for the detailed recommendation anyway. I think we'll stick to this model in the end, as it is still not difficult to develop and test submodules independently. Though their updates will affect the whole application recompile and redeployment. On Mar 26, 6:35 pm, kozura <[email protected]> wrote: > Well I'm not sure what you mean by the main module "inheriting" the > submodules. From what you described, the main module sets up the > general framework of the page, and then insert the various, fairly > independent submodules based on data or user interactions. > > This is exactly what code splitting is designed for. Yes, you are > still writing the whole thing as one giant monolithic application. > But if the submodules are written as fairly independent components > with a small number of entry points and few (best: no) places where > the main app makes specific calls into particular submodules (read: > use Observers or abstract classes/interfaces), then you can set up > those entry points as code splits. GWT then uses aggressive > dependency checking to optimally fragment the code to only load what > is needed for a given module when it gets used. So you get the best > of both approaches - you can write your application without having to > deal with the complexities of splitting it up into multiple > components, but still get the huge benefits of optimal dynamic > loading. > > This works especially well if the framework you are using is pure GWT > java, vs a wrapped javascript library. The dependency checking is at > the method level, so it will figure out what pieces of the framework > each code split needs, and as more submodules are loaded will ensure > the correct bits of framework are also loaded. > > As you mention, the GWT compiler does operate on the entire > application, so it recompiles everything, every time. If you're using > OOPHM for development, this really mainly impacts deployment time. > > So again I highly recommend this method for this type of application, > let the tool do the work rather than trying to come up with a > complicated scheme that will be suboptimal and hard to maintain. > > On Mar 26, 2:27 am, ome <[email protected]> wrote: > > > > > Yes, sure I've seen this. You could easily load lots of code > > asynchronously using both approaches. But you will not remove > > dependencies in the compile time and main module will still inherit > > all other submodules, right? And if you change one module you have to > > recompile everything? -- 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=en.
