[Engine-devel] Dynamic resource loading in GWT

[Roy Golan]

On Wed 07 Aug 2013 03:23:36 PM IDT, 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.
>
> 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.
why?
and what number is large?
>
>> 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,

isn't admin is gaining from it? and development time and bugs around 
messages?

 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.

in the end both are cached so there is no memory overhead.
>
>
>>> ----
>>> 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