It's not entirely clear yet that it's "going" to be implemented, at least not in bounded time; it's on my personal wish-list to do, but time is short and that list long. There's no specific internal "need" driving it, either; I just got to help out a project which had decided to make private patches on GWT for their new user agents... in untangling them from that mess, I was reminded of how this would be desirable, and posted this version of the thread, reopening a discussion I'd initially been oblivious to a year ago.
I'm still ruminating on Bob's note about generators; I can see that they should be able to check both equals and matches-by-inheritance, but still think most won't care (which should make updating easier). On Wed, May 13, 2009 at 2:14 PM, Ray Cromwell <[email protected]> wrote: > > This is now the third time this feature has been brought up, here's > the original thread: > > http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/8bd9fe0a2676c4a2 > > I'm gathering now there's an internal need for it and it's finally > going to be implemented? :) :) > > -Ray > > > On Wed, May 13, 2009 at 9:17 AM, Lex Spoon <[email protected]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
