On Tue, May 5, 2009 at 10:42 AM, BobV <[email protected]> wrote: > If you choose to go this route, GeneratorContext will need a "boolean > propertyMatches(String propName, String value)" method to handle the > hierarchical case and all existing generators that are sensitive to > any deferred-binding properties will have to be updated to this API to > prevent spurious breaks. > """ > > Furthermore, based on Freeland's reply: > > If the "iphone" value just maps onto the "safari" value for everything > but rule-selection purposes, how could you then write "@if user.agent > iphone" to dial in presentation in a bit more? The ClientBundle system > returns differently-named types for each permutation based on feedback > from the individual ResourceGenerators, (e.g. > MyResources_en_US_safari). > > My basic point is that the specific value of the deferred-binding > property is meaningless in the presence of extension values and the > only useful question is "does this match" as opposed to asking "is > this equal". Developers who write Generator that use deferred-binding > properties to alter code-generation must update to a new API in order > to prevent flaky behavior. >
That sounds right to me. It would make sense to add that part first and start switching people over. Also, +1 to having declared property inheritance rather than string matching. Philosophically, it's a red flag to care about the string name of an identifier. There are a lot of pragmatic issues, too. To name one, all the deferred binding rules that are against safari would need to be bulk rewritten to use a regex instead. The resulting code will be noisy, and we'll need to remember to add this boilerplate for all deferred binding rules in the future. Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
