Thanks for the notes on the two functions - nice to know about them!
--Sri
2010/1/4 Sripathi Krishnan <sripathi.krish...@gmail.com>
> Is there any way to extend that code in UserAgent.gwt.xml without copying
>> it verbatim or hacking it up in-place?
>>
> Don't see a way out other than copying <property-provider> to your
> module.gwt.xml and making modifications. At least you don't have to hack up
> UserAgent.gwt.xml.
>
> Its not too bad, in my opinion. Adding support for a new browser is pretty
> widely announced, so you'd know when you have to update your copy of the
> code.
>
> --Sri
>
>
> 2010/1/1 Todd Vierling <t...@duh.org>
>
> In Gmail, for instance (yes, I know it predates GWT, but please bear
>> with me for a moment), it's possible to override browser detection and
>> run against an unsupported browser for various reasons. So I've been
>> dissecting the nocache.js in Detailed compile mode to see if this sort
>> of thing might be possible in GWT.
>>
>> First thing I noticed was that the meta tags "gwt:onLoadErrorFn" and
>> "gwt:onPropertyErrorFn" are not officially documented at all, and only
>> mentioned in passing in a few threads here. They seem pretty
>> straightforward, and here's what they appear to do upon human-eye
>> interpretation. (Please feel free to copy this to the official doc and
>> expand upon them, as they appear to be VERY useful and deserve
>> official mention.)
>>
>> ===
>> gwt:onLoadErrorFn:
>> Javascript function name in page global scope, which is called in
>> the host page's onLoad hook when loading of the cacheable bits fails.
>> Called with two arguments: the rename-to name of the module; and the
>> base URI of the host page (calculated from the topmost included script
>> file URI; if that can't be determined, uses the <BASE HREF> value of
>> the host page if present; and finally uses the host page URI with any
>> filename part trimmed as a last resort).
>>
>> gwt:onPropertyErrorFn:
>> Javascript function name in page global scope, which is called when
>> a GWT global property value falls outside the set of allowed values
>> for that property.
>> Called with three arguments: the property name; an array of the
>> allowed values for that property; and the invalid value.
>> ===
>>
>> So if an unknown browser type is detected, what happens is that the
>> gwt:onPropertyErrorFn is called with the arguments ('user.agent',
>> [...known permutations...], 'unknown'). OK, so implementing a hook to
>> do something useful on an unknown browser is pretty easy.
>>
>> Here's the harder part that I can't figure out: Is there a way to
>> specify that certain User-Agents (that aren't already hardcoded into
>> GWT's detection code) map to a given user.agent value? I see the
>> <property-provider> code in com/google/gwt/user/UserAgent.gwt.xml, but
>> that seems pretty much fixed in stone.
>>
>> The idea would be to have additional code that I could use to map
>> user.agent values, coercing currently-unsupported browsers into a
>> given JS dialect to provide at least some application usability. Is
>> there any way to extend that code in UserAgent.gwt.xml without copying
>> it verbatim or hacking it up in-place?
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To post to this group, send email to google-web-tool...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
