[Engine-devel] Dynamic resource loading in GWT

Thu Aug 8 08:45:31 UTC 2013

Disclaimer: I don't understand the inner workings of GWT, its interplay
with the browser and so forth. Some comments are interleaved below.

On 07/08/13 15:23, Alexander Wels wrote:
> On Wednesday, August 07, 2013 02:48:45 PM Roy Golan wrote:
>> On 08/07/2013 02:08 PM, Einav Cohen wrote:
>>> Hi Roy,
>>>
>>> a couple of notes (I could be totally wrong here, GWT experts - please
>>> review/comment):
>>>
>>> - from [1]:
>>> "Provides dynamic string lookup of key/value string pairs defined in a
>>> module's host HTML page" - there is a chance that a gwt dictionary is
>>> limited to reading key/value string pairs that reside within the *gwt
>>> module host HTML page* (i.e., within the context of the GWT application -
>>> "http://[server]/webadmin/webadmin/...") and not outside - need to find
>>> that out.
>> well the file servlet resides on [server] so I don't think there a "same
>> origin policy" problem here - correct me if I'm wrong (isn't branding
>> doing something similar?)
>>
> 
> Branding is doing exactly what you are suggesting, generating a dictionary in 
> the host page, and having the GWT application read it at runtime. The only 
> reason we did it like that, is that there is no other way of changing some of 
> the messages at runtime. If there was some way of doing it at compile time I 
> would have done that. Also the number of resources changed by branding is very 
> limited and therefore won't impact the performance as much as doing every 
> single resource.
> 

I have no idea how difficult it would be to implement a sample case. If
it's not too difficult, why not give it a shot and see if there's
actually an appreciable performance hit?

> There are advantages and disadvantages of both methods that need to be 
> carefully weighed, and the GWT developers themselves did that and came to the 
> conclusion that compile time inclusion is the best method for most resources. 
> They did however anticipate the need for some runtime resources so they 
> included Dictionary etc.
> 
>>> - again, from [1]:
>>> "a variety of error conditions (particularly those involving key
>>> mismatches) cannot be caught until runtime. Similarly, the GWT compiler
>>> is unable discard unused dictionary values since the structure cannot be
>>> statically analyzed".
>>> (this is expected, as the suggested loading here is dynamic, rather than
>>> static)
>>>
>>> - not sure exactly how this would work with localization; there is "A
>>> Caveat Regarding Locale" mentioned in [1] - IIUC, we will lose the
>>> automatic locale-mapping that we have today, and we would need to do it
>>> ourselves somehow (not a big deal, I suppose, just some extra work that
>>> needs to be done here).
>>
> 
> The branding allows one to define java property bundles for all the supported 
> languages, and will load them at runtime and put the translated strings in the 
> Dictionary in the host page. Again I wouldn't recommend doing it for a large 
> number of resources.
> 
>> indeed but it will pay off. a change off resources means ctrl+F5 and not
>> GWT compilation :P
>>
> 
> Sure for the developer it would be great, less compiling. However for the user 
> not so much, and in the end we are creating the software for the user and the 
> needs of the developer are secondary to that. When I say it is not so great 
> for the user, I mean the fact that it becomes a lot harder to cache the host 
> page (as the contents can change), vs caching the compiled resources is really 
> easy as the contents won't chance.
> 

It's not just about the "needs of the developer" - the way the error
messages are distributed between different files is prone to errors, and
things that are prone to errors eventually will hurt the user.

> 
>>> ----
>>> Thanks,
>>> Einav
>>>
>>> [1]
>>> http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dicti
>>> onary.html
>>>
>>> ----- Original Message -----
>>>
>>>> From: "Roy Golan" <rgolan at redhat.com>
>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Wednesday, August 7, 2013 2:59:07 AM
>>>> Subject: [Engine-devel] Dynamic resource loading in GWT
>>>>
>>>> Painful issue here - we all know the regular drill of maintaining
>>>> messages in many places, I18N files and so on.
>>>> Also there's a patch to make all available timezone an java enum and by
>>>> that share it for free with the UI. its a way better than a backend
>>>> Query.
>>>>
>>>> But this is all hard-coded, not flexible, hard to maintain, we all know.
>>>>
>>>> Why won't we make GWT load a javascript dictionary/dictionaries from a
>>>> servlet or our host page html[1] using GWT Dictionary[3]?
>>>>
>>>> that way the configuration is shared with the engine, it relies on the
>>>> disk, customers and GSS can change it on-site and so on.
>>>>
>>>> | index.html | -> | file servlet | -> |read /etc/ovirt-engine/conf/...|
>>>> | 
>>>>       ^
>>>> | 
>>>> | GWT loads Dictionary |
>>>>
>>>> candidates for dynamic resources
>>>> * I18N resources AppErrors...
>>>> * config ( just the UI subset )
>>>> * osinfo ?
>>>>
>>>>
>>>>
>>>> [1] host page html -
>>>> http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html#DevG
>>>> uideHostPage [2] Dynamic string internationalisation -
>>>> http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicStr
>>>> ingInternationalization [3]
>>>> http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dicti
>>>> onary.html
>>>>
>>>> Thanks,
>>>> Roy
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 