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" <rgo...@redhat.com>
To: aw...@redhat.com
Cc: engine-devel@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" <rgo...@redhat.com>
To: "engine-devel" <engine-devel@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
