No announcement yet.
  • Filter
  • Time
Clear All
new posts

  • Enhancement: Customized fmt-tag DataSource localization

    Hi Isomorphic,

    I'm using current 6.1p with fmt-tag DataSource localization for .ds.xml (and .type.xml) files for servercode and fieldnames and GWT permutation localization for the client side.
    This all works very well.
    Now as our product targets different industries with slightly different terminology, the default column names and lables don't always fit perfectly.
    Here I build a way to "overwrite" the properties from client side GWT permutations with customized DB content.
    Now the same is needed for column names as those also don't always fit the default name. Right now I have an extra branch with hardcoded changes for the one customer that requested this first. Of course this is not a real solution.

    Could you support a new attribute within the
    <fmt:bundle basename="com.isomorphic.test.i18n" />
    in the .ds.xml header, that specifies by default the class you use for this:
    "Note: The tags we use for internationalizing Smart GWT XML files look like standard JSTL tags; this is intentional, simply because developers are familiar with JSTL. However, the tags are being processed by Smart GWT code, not JSTL, so only the specific tags documented here are supported."
    I'd then subclass that class, @override the method and do a "if (translated in DB) return translation; else return super(...);".
    This way, DataSourceLoader would then return my default strings, or, if customized, the customer-provided strings.

    Thank you & Best regards

  • #2
    This would be a valid Feature Sponsorship for a future version if that's what you'd like to do.

    Another way to achieve this would be to use the existing DynamicDSGenerator API. Discussion for this starts in the QuickStart Guide, beginning of the Server Framework chapter.


    • #3
      Hi Isomorphic,

      I assume that this would be a small enhancement, correct? Could you also add it to 6.1p?

      The DynamicDSGenerator would work as well, thanks for the hint. But the other way would be more declarative IMHO.
      Also, w.r.t. to these docs (last paragraph), I'd most likely loose DS-pooling more would need to be very careful with the configuration, if I use a DynamicDSGenerator for all DataSources.

      Out of interest:
      I'm already using DynamicDSGenerator for a few DS. This will become more.
      If I ever need more than one Generator/Modificator, is it possible to chain them, and if so, how? Here you say, they are called in a LIFO manner and if one feels responsible, it will return the DS (and then no further modification is possible).
      This would be better than having a Generator per DS, wouldn't it?

      Because as the changing of the titles would affect all DS, I'd now need two Generators/Modificator for the DS where I'm already using a DynamicDSGenerator now.

      Best regards


      • #4
        No, we wouldn't backport this one to an existing release. It would involve multiple new APIs, and the more we're looking at this, the less likely it seems that anyone else would ever use it, given the ability to use Dynamic DataSources to do this already.

        See the Dynamic DataSource APIs - you can register multiple generators for different prefixes. There is no way to do something like provide a DataSource and then have another generator further modify it, so simply factor your code so that all modifications happen in a single generator.

        See this overview on pooling. Pooling can be enabled for Dynamic DataSources so long as you are not trying to return different DataSources for the same DataSource ID, which should not be necessary in your case.