On 9 fev, 02:13, Brendan Kenny <bcke...@gmail.com> wrote: > 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.
Hi Brendan, Thanks for the explanation. Now I understand that the best way would be using a single gwt module, and let the compiler try to discard the unused code. There is no need for a framework's module to be a gwt's module. You are right about GIN too. I didn't know about this project, and it really seems to be what I need. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
