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" <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