I'm not sure I understand the larger picture, but I think there are some issues with this approach. Perhaps we can connect up to discuss further....Here are some of the main points to consider:
1. StandardRebindOracle should not know anything specific about a specific generator, so SRO is not the right place put UiBinder specific code. 2. The typeNameBindingMap is just a 1 to 1 lookup of source type names to generated type names, and it gets reset each time there's a new StandardRebindOracle (e.g. everytime there's a refresh in dev mode). It does not contain any cached data from a previous generator run. So typeNameBindingMap is not related to generator result caching. 3. The RebindCache that gets passed to the ShellModuleSpaceHost is available for generators to make use of, if they so choose. So a generator implementation can choose to save data in the cache so it can consult it later in a future rebind, to see if it can make use of it. It would be wrong for UiBinder specific logic to invalidate the RebindCache for other generators. 4. Generator Result Caching (of which RebindCache is a part of) is in it's infancy, and is only enabled currently with the experimental flag -XenableGeneratorResultCaching 5. Generator Result Caching has only been submitted so far for RPC, and soonly for ClientBundle, but not yet for UiBinder, so by default, this should not be an issue for UiBinder at present. 6. I am likely to start looking at implementing Generator Result Caching for UiBinder shortly, so at that time, perhaps we can work together to resolve the issue of caching during designTime, etc. I expect it will be straightforward, within the UiBinder generator, to let it make it's own determination as to whether to make use of previously cached data, based on designTime (or any other criteria)... Jason http://gwt-code-reviews.appspot.com/1275801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
