Sounds nice, although the next logical step would be to ask for permutation
processing hooks. What happens if I define a user.agent "safari-mobile" but
the JavaToJavaScriptCompiler executes some visitors for the "webkit" user
agent? I assume they won't get executed anymore.
As an example, I had forked JavaToJavaScriptCompiler because I wanted to
add a visitor that disables JIT in Safari on mobile devices because of some
issues. Instead of forking, it would be a lot cooler if I could do:
<extend-property name="user.agent" value="safari-mobile" />
// instead of your user.agent.xyz.predicate
<extend-property name="user.agent.safari-mobile.permutation.plugin"
value="com.example.gwt.permutation.SafariMobilePlugin" />
class SafariMobilePlugin extends WebKitPlugin {
@Override
String getRuntimeMatcher(String userAgent) {
return "<some detection JavaScript for the bootstrap file>";
}
// methods to customize permutation compilation, e.g. adding additional
visitors. By calling a super method the WebKitPlugin code/visitors would
also execute if desired.
}
Even if we now do not provide compilation hooks I think it could be a
future proof approach having classes that stand for one permutation.
Generating the user agent detection code could then easily be done by
iterating through all "permutation plugin".getRuntimeMatcher() and combine
them into one JS method.
-- J.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
