On Feb 8, 10:04 pm, Brendan Kenny <bcke...@gmail.com> wrote: > On Feb 8, 6:34 pm, Luiz Mineo <luiz.mi...@gmail.com> wrote: > > > On 8 fev, 13:23, John Tamplin <j...@google.com> wrote: > > > On Mon, Feb 8, 2010 at 6:04 AM, Luiz Mineo <luiz.mi...@gmail.com> 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/c... > 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.
Actually, rereading your last post, have you looked into using GIN? http://code.google.com/p/google-gin/ It seems like what you're trying to accomplish is largely independent of module definitions and is more about smart dependency injection. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
