On Feb 8, 6:34 pm, Luiz Mineo <[email protected]> wrote: > On 8 fev, 13:23, John Tamplin <[email protected]> wrote: > > On Mon, Feb 8, 2010 at 6:04 AM, Luiz Mineo <[email protected]> wrote: > > > I'm dedicating some of my time to develop a small framework, to help > > > me create and maintain big GWT apps. I'm already doing some really > > > useful things with generators, but one of my objectives is offer the > > > option to create a lot of modules, without the need to maintain a lot > > > of *.gwt.xml files, and let the developer choose what modules will go > > > to the final build, and what won't. For now, I'm trying to achieve > > > this with an standalone app that is executed before the compiler or > > > devmode, but I'm looking for a better solution. > > > > Is there any way to create or alter a module (like adding new source > > > paths) during compile time, using something like generators? Also, is > > > it possible to retrieve informations about the current module (name, > > > path...) in a generator? From what I could get from the GWT source, > > > it's not possible, but any idea would be appreciated =] > > > It is not possible currently to modify or create modules, and there is no > > API for accessing module-level info from a generator. As a philosophical > > point, we want to keep the generator API constrained so that we can make > > improvements to it -- for example, we are looking at adding generator > > dependency checking so generators can avoid being run if nothing they depend > > on has changed. > > > What exactly would be accomplished by having a generator create a new > > module? The programmer will still have to specify to include it, and that > > might as well be in a module file with inherits. The generator can then > > create whatever types it needs based on generate-with rules in that module. > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google > > Thanks a lot for the answers. > > My idea is create a framework that improves the reusability of code > between GWT apps. Each app will be made up by several small modules, > wich will be able to be shared. There will be basically three kinds of > modules: Controllers, Presenters and Definitions (the public > interfaces implemented by the other two modules). The dependencies and > communication between modules will be specified with annotations, and > the framework will be responsible to control them. > > To avoid the need to maintain a *.gwt.xml for each module, I have > looking for a way to let the programmer specify what modules will be > included in the app with a single *.xml file. My current solution is: > - The programmer writes a main *.xml file, that is a normal *.gwt.xml > file plus some tags to specify what modules will be included > - The programmer executes a simple java app (included in the > framework) that copy the *.xml file to a new *.gwt.xml file, changing > each module's tag to one or more <source path="..."/> tag. The app > also generates other *.properties files, that will be consulted by > generators during compile time. The final *.gwt.xml file is what will > be read by the GWT compiler. > > So, what I'm looking for is a way to "plug" that program in the GWT > compiler, but I have no idea of what would be the best way to do this.
Hi Luiz, I've mucked around in ModuleDef, personally: http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java but it won't really do what you seem to want to, and as John noted above, a solution based on it will in all likelihood break (possibly subtly) in the future. If I'm correctly understanding what you're trying to do, just be aware that there are other approaches. If you absolutely need a large set of small modules, it seems like a module file + generator would function as a full equivalent to a module created dynamically based on a set of parameters (this is John's point too). If not, a more monolithic module that contains a large group of generators seems like it would function just as well--there's no penalty for unused code (well, at runtime), definitely no penalty for unused generate-with statements, and the GWT compiler is already optimized for this kind of use case. It seems a little bit like you're trying to create a meta-object- hierarchy via a build system, when that's already one of the big gains of being able to use java and deferred binding in the first place. It might in fact lead to development regressions, for instance in the division of how a user would have to define a project: a bunch of inherit (and whatever else) statements in the module file don't get the multiple benefits of code completion/type checking that e.g. annotations do...which already have built-in generator support. However, all of that certainly doesn't mean that generators+linkers can already meet all needs. And just because something shouldn't be done doesn't mean it can't be done (you just have to fix if yourself if it breaks). I'm happy to share what knowledge I have if you have more questions. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
