Enhancement: Customized fmt-tag DataSource localization

[Blama]

Hi Isomorphic,

this one was forgotten here by me and perhaps also by you. I just wrote your colleague Lee w.r.t to the next steps.

Regarding DS pool it seems the function already exists, I stumbled upon it by chance: DataSourceManager.clearPooledInstances():

There isn't a fmt-cache. Yes, you would need a way to clear the DS pool if it's critical for some reason to avoid a server restart, but at least clearing the DS pool is a feature someone else might use.
Both approaches, if sponsored, would only be available in future release, so the prefixing + DynamicDSGenerator would be the approach that works with current releases.

Best regards
Blama

[Blama]

Hi Isomorphic,

There isn't a fmt-cache.

But you are writing in the docs that you use normal java ResourceBundle, which does cache. So even if you don't have a cache, that "Clear pool" method must also trigger a resourceBundle.clearCache().

Overall though, we're surprised you're bothering. Presumably these i18n labels are updated infrequently, in a batch. Restarting the server to add support for a new language seems like a pretty ordinary thing to do.

Perhaps you are right. I do not expect frequent changes after initial setup. But if these happen, it's hard to tell the customer that they have to wait for a web application restart to see their changes. Also I think that it is way more easy for me to just intervene in the fmt-subclass.

Both approaches, if sponsored, would only be available in future release, so the prefixing + DynamicDSGenerator would be the approach that works with current releases.

That's a pity, but if it is that way, it is that way. As of today, I only have one branch with customer specific field title changes.
Can you send me an offer of those two features to my company email address?


Thank you & Best regards
Blama

[Isomorphic]

There isn't a fmt-cache. Yes, you would need a way to clear the DS pool if it's critical for some reason to avoid a server restart, but at least clearing the DS pool is a feature someone else might use.

Both approaches, if sponsored, would only be available in future release, so the prefixing + DynamicDSGenerator would be the approach that works with current releases.

Overall though, we're surprised you're bothering. Presumably these i18n labels are updated infrequently, in a batch. Restarting the server to add support for a new language seems like a pretty ordinary thing to do.

[Blama]

Hi Isomorphic,

it does not need to be real time, but it should not involve a Tomcat restart or application reload.
This is, why I'd need the following with 4)

• Button to
  • Generate .properties files from DB content
  • Clear DS pool
  • Clear fmt-cache (if you keep one)

Additionally it would mean all DS are dynamic and that I exchange the default-fmt tags against special ones like you describe here:

Specify the bundle name in the individual <fmt:message> tags, like this:

<title><fmt:message key='title1' bundle="com.mycompany.MyProperties" /></title>

Overall, this seems way more complicated and fragile than subclassing your fmt-Resource bundle class. I also assume that "Clear DS pool" and "Clear fmt-cache" are also not possible right now, so it will mean some new (or exposed) feature anyway.

Best regards
Blama

[Isomorphic]

Yes. And so again unless you need the ability to update these labels at runtime, while users are still interacting with the app, approach 4 (or variants such as doing the generation as a deployment step, or changing the file and restarting the server) should be fine.

[Blama]

Hi Isomorphic,

is this list of options complete from your point of view?

1. Feature sponsorship
2. Dynamic (and prefixed DS) with DS pooling
3. Dynamic (and un-prefixed DS) without DS pooling
4. Idea: Generating properties files from DB content on startup(?)
5. Temporary: Extra branch with hardcoded changes (as done currently)

If so, only 1. and 4. are viable options IMHO.

Regarding 4.:
This would be possible only if there is currently a way to enforce cache clearing for your fmt-cache (if you keep one).
Most likely, this would also make it necessary to clean the DataSource pool. The more I think about it, only 1. seems to be a good way of doing this (see #1 for the feature).

Best regards
Blama

[Blama]

Hi Isomorphic,

If you do that, with pooling enabled, you'll end up loading DataSources with the wrong titles because DataSources will be taken from the pool with the titles already in place from the request that initially created the DataSource.

I already assumed this. I'd really like to do this without Dynamic (and therefore prefixed) DataSources.

Are you trying to make it possible to make runtime changes to these titles? If not, then just generate static properties files whenever the titles are changed.

Yes, that's exactly what I want to do:

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.

Best regards
Blama

[Isomorphic]

If you do that, with pooling enabled, you'll end up loading DataSources with the wrong titles because DataSources will be taken from the pool with the titles already in place from the request that initially created the DataSource.

You could use an approach where you create separate pools by prefixing the DataSource ID with the locale. However, it's unclear why you're going down this path at all. Are you trying to make it possible to make runtime changes to these titles? If not, then just generate static properties files whenever the titles are changed.

[Blama]

Hi Isomorphic,

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.

OK, I already assumed this. Should not be a problem.

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.

Yes, pooling will be possible, one just has to be very careful.
W.r.t to this: I know that it would not be a problem most likely, but the DataSource returned would not be the same bitwise.
As the custom translations differ per language and as I will have them in the DB, I can't use .properties files in this case.
For for all fields where the default (fmt-localized) title is overridden, I'd remove the fmt-tag and put the plain translated content. This would differ per http-request language and therefore mean different results.
I'm pretty sure this is no problem for the IDACall request flow, but perhaps for DataSourceLoader?

Best regards
Blama

[Isomorphic]

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.

[Blama]

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
Blama

[Isomorphic]

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.

[Blama]

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
Blama