[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#DevGuid... [2] Dynamic string internationalisation - http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicString... [3] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictiona... Thanks, Roy
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. - 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). ---- Thanks, Einav [1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictiona... ----- Original Message -----
From: "Roy Golan" <rgolan@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#DevGuid... [2] Dynamic string internationalisation - http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicString... [3] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictiona...
Thanks, Roy _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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?)
- 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). indeed but it will pay off. a change off resources means ctrl+F5 and not GWT compilation :P
---- Thanks, Einav
[1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictiona...
----- Original Message -----
From: "Roy Golan" <rgolan@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#DevGuid... [2] Dynamic string internationalisation - http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicString... [3] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictiona...
Thanks, Roy _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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.
---- Thanks, Einav
[1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dicti onary.html
----- Original Message -----
From: "Roy Golan" <rgolan@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
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@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
[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. 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@redhat.com> To: awels@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" <rgolan@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
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@redhat.com> To: awels@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" <rgolan@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
----- Original Message ----- From: "Roy Golan" <rgolan@redhat.com> Sent: Thursday, August 8, 2013 5:14:57 AM
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?
in general, loading dynamically (in run time) data that is already "known" in compilation time doesn't make much sense to me. having said that, after giving it some more thought: I agree with you, and the reason for that is that there is a chance that "tomorrow", the GUI and the engine-core might be separated to different projects/repos/etc., so sharing resources between them during compilation time might be very challenging. so I think that you can definitely start with a POC of timezone loading, however we (GUI maintainers) must give some serious thought on resource sharing in general (in case we will indeed move towards separating the GUI from the core), given the fact that the gwt infrastructure / concept contradicts dynamic loading, in a sense.
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@redhat.com> To: awels@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" <rgolan@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
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@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
Hey Roy, well, I'm not a fan of using the dictionary - it is an associative array and opens a door to mistakes which will not be handled by compiler like locales.get("naem") will not return me the name :) At least not for data we know how will look like (e.g. for the os info) We already embed some info into the host page and use it on the client using JavaScript Overlay Types [4]. You can have a look for example at GwtDynamicHostPageServlet: request.setAttribute(MD5Attributes.ATTR_USER_INFO.getKey(), getUserInfoObject(loggedInUser)); and on the FE side the overlay type is: AutoLoginData But I would be careful how much info do we want to embed into the host page - it can make it significantly big and influence the performance (for example we are using code splitting [5] to download only the parts of the app we actually need when we need them). To embed too much info which is not always needed is a step to the opposite direction. I don't say it is wrong, it just has to be considered. Tomas [4]: http://googlewebtoolkit.blogspot.cz/2008/08/getting-to-really-know-gwt-part-... [5]: http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html ----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, August 7, 2013 1:08:58 PM Subject: Re: [Engine-devel] Dynamic resource loading in GWT
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.
- 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).
---- Thanks, Einav
[1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictiona...
----- Original Message -----
From: "Roy Golan" <rgolan@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#DevGuid... [2] Dynamic string internationalisation - http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicString... [3] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Dictiona...
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
On 08/07/2013 08:10 AM, Tomas Jelinek wrote:
Hey Roy,
well, I'm not a fan of using the dictionary - it is an associative array and opens a door to mistakes which will not be handled by compiler like locales.get("naem") will not return me the name :) At least not for data we know how will look like (e.g. for the os info)
We already embed some info into the host page and use it on the client using JavaScript Overlay Types [4].
You can have a look for example at GwtDynamicHostPageServlet: request.setAttribute(MD5Attributes.ATTR_USER_INFO.getKey(), getUserInfoObject(loggedInUser)); and on the FE side the overlay type is: AutoLoginData
But I would be careful how much info do we want to embed into the host page - it can make it significantly big and influence the performance (for example we are using code splitting [5] to download only the parts of the app we actually need when we need them). To embed too much info which is not always needed is a step to the opposite direction. I don't say it is wrong, it just has to be considered.
Tomas
[4]: http://googlewebtoolkit.blogspot.cz/2008/08/getting-to-really-know-gwt-part-... [5]: http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html
there is still the point of having multiple files, which seems like an easy win by merging to a single file, and if needed, using pre-compile to create the cloned files
participants (6)
-
Alexander Wels -
Einav Cohen -
Itamar Heim -
Lior Vernia -
Roy Golan -
Tomas Jelinek