[Engine-devel] Dynamic resource loading in GWT

Roy Golan rgolan at redhat.com
Thu Aug 8 09:14:57 UTC 2013 

On 08/07/2013 04:50 PM, Einav Cohen wrote:
> [top posting]
>
> in general, gwt applications are not "built" for loading things at run-time.
> for the branding feature, we had to change some of that due to the feature
> requirements.
>
> question is what will we gain from loading dynamically the values that are
> currently being loaded statically.
> for features such as dynamic/user-defined OSs [1] - it makes sense and probably
> even required, however, for error messages, which are not dynamic/user-defined,
> I think that it doesn't.

error messages changes when the engine changes them. the fact that there 
is 1 source and 3 copies is a mess
so the point is not about making the error message "dynamic" - its about 
loading them always from the same source
i.e - instead of error.js created by GWT(or whatever its hiding in) load 
it from [server]/fileServlet?f=errors

also its not only about error messages.
Virt team want to load the system timezones. today its done via Query - 
Query should be used to get Entities no sources
I'm sure lots of things are limited/complicate impl/buggy by the lack 
easy way of resource sharing.

we can start with a POC which will be used to load Timezones what do say?


> there are other ways to ease maintenance of error-messages (e.g. maintain only
> one copy of each file, and copy it during compilation time to the relevant
> locations, instead of maintaining several identical files), without introducing
> the disadvantages of dynamic loading.
>
> ----
> Thanks,
> Einav
>
> [1] http://www.ovirt.org/OS_info
>
> ----- Original Message -----
>> From: "Roy Golan" <rgolan at redhat.com>
>> To: awels at redhat.com
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, August 7, 2013 9:35:30 AM
>> Subject: Re: [Engine-devel] Dynamic resource loading in GWT
>>
>> 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
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>>

More information about the Devel mailing list