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(a)redhat.com>
>>> To: "engine-devel" <engine-devel(a)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(a)ovirt.org
>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel