Here's my original email to Freeland: """ What does this mean for generators that are sensitive to the user.agent property (or any other property that may be extended)?
Imagine that a common component has a CssResource with an "@if user.agent safari" rule. The end-developer comes along and extends the safari rule with "iphone" and "android" extensions. It's no longer just a simple string comparison to determine if the user.agent value the generator is looking for actually matches the permutation that's currently running. 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. -- Bob Vawter Google Web Toolkit Team --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
