Hugh Gibson schrieb: >>> 2. Dynamic loading. >>> >>> This works as now - i.e. an instance of qx.locale.LocalizedString >>> is created and evaluating the string value is carried out in >>> "toString". Instances have to listen for changes to the locale and >>> reload their values. All localised strings will re-evaluate their >>> current values but using the new locale. >>> >>> I don't see any problems with this. It would be a compile-time >>> option. If you want dynamic translation you enable it and take the >>> hit of extra objects. If you want fast and lean, you disable >>> dynamic loading and predetermine the locale and runtime. >>> >> The problem is that in the second case the type of object routed >> between classes is not a string, but a instance of a qooxdoo class. >> This is fundamentelly more complex and different. Every type check >> must handle this correctly etc. >> > > I looked at the existing code (trunk and legacy_0_7_x) and there are no > type checks of qx.locale.LocalizedString outside of the class itself and > the translation management code. qx.Locale.LocalizedString handles > conversion to a string with toString so it can look like a string object > as needed. Where else is type checking needed on the object returned from > this.tr etc? If it's type checking in a property it's trivial for you to > make qx.locale.LocalizedString be a "String" (and to change the property > value when the locale changes). > > I thought that the issue was that reload is needed on objects which have > strings when the locale changes, so they need listeners for that event > and so on. But it seems to me that you've done most of the work needed > here. Why throw it away when it can easily be made optional as I have > described? > > Your justification for removing this facility, which has been shown to be > of real use in some cases, is that it adds overhead for everything. But a > simple optional change - just making the this.trn call effectively > transparent, fixes all that. > Performance and memory consumption is only one aspect. The other one, which I regard equally important, is code complexity and maintainability. When we initially implemented dynamic theme switching it seemed like an easy thing to do. We thought we just had to make the label widget aware of locale changes but things are never that easy. Very soon other widgets popped up, which needed special handling. Each widget, which displays text outside of label widgets, needed to be able to handle locale switches as well. Further all widgets displaying any time or date related data have to cope with it as well. This aspect is spread all over the qooxdoo ui codebase. Its the sum of all of this, which has become a real maintenance issue and which I don't want to port to 0.8.
You are absolutely right that with your approach we could remove the performance import for a static language version. My problem with your suggestion however is that it will reduce none of the mentioned complexity and will add just another layer on top of it. I hope I could make my opinion clear :-) Best Fabian -- Fabian Jakobs JavaScript Framework Developer 1&1 Internet AG Brauerstraße 48 76135 Karlsruhe Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
