[Blama]

Hi Isomorphic,

perfect, thank you.

Best regards
Blama

[Isomorphic]

The only scenario in which we would add a cache here in a release version would be if we found it was creating a performance problem bad enough that it is rightly regarded as a bug. Seems extremely unlikely here.

If caching needs to be added, we can add a flag to disable caching.

[Blama]

Hi Isomorphic,

all understood. And good to know that it works now (or, more specific, with 12.1). I assume that you would not introduce changes here in a nightly, but only in new major or minor versions, correct?
Also good to know that you say that if the caching is enabled at some point in the future, a server restart would be sufficient to pick up the right string (=cache would be per (suffixed) DataSource+fmt-String, not just fmt-String only).
In this case we would only loose live editability, which is not good, but also not as bad as a fallback to default strings or a random whatever-gets-requested-first-and-cached result.

But given the fact that you built the feature for us and that the thread mentioned "slightly different terminology" as use case already in the 1st post, I assume that you would also build a possibility to disable the cache, correct?
This would then be perfectly fine or me, as the strings will come from the DB and I'll implement an application-side cache there.

Finally I think it is good for all users to have a list of points to watch out for in a SmartGWT based SaaS / Multi-Home product here in a single thread. Do you think it would make sense to extract the relevant points here in a docs entry, perhaps linked from the Quick Start Guide?

Best regards
Blama

[Isomorphic]

At the risk of sounding like a broken record: it's not reasonable to expect no caching of localization. Translations to other languages do not normally change. If a language pack is updated by the application designer, it's reasonable to restart the server to get the new translations.

Industry-specific or customer-specific terminology, especially if updated *by the customers themselves*, is a totally different thing. It makes sense that it might change at runtime.

When you try to achieve industry- or customer-specific terminology via a system designed for localization, that's a hack, and you should expect it to break. There doesn't happen to be caching right now, but we cannot commit to never implementing caching strategies that would be perfectly reasonable in the context of localization, but would break your use case of customer-specific terminology.

[Blama]

Hi Isomorphic,

Ah, ok. Sometimes it takes really long via written messages until both participants have the same understanding.

It's customer-specific terminology. But once I use suffixed DataSources per customer, this should not matter for the framework, or does it?
I mean where is the difference if I translate Reseller to "Händler" or "Vertreter" - both are just strings.
The only thing different is that I already provide a default translation that one can use or overwrite.

I agree that the setting is very very odd, but we are not in the position of some big CRM vendors to dictate terms (no pun intended).
Also, the customer group we are targeting the most often has reluctant Partners/Resellers/Dealers/Brokers that sometimes are not very computer savvy and was just used to work with Excel (or even pen and paper) before.
So the application has to be dead easy for them from usage and wording.

Handling the latter via localization is a hack.

That is why I asked here

OK, but what would be an non-hackish solution worth the necessary effort to the task in your opinion, if the application is the same otherwise?

Best regards
Blama

[Isomorphic]

OK the new piece of information here is that the customers themselves are actually updating your translation packs. That is very, very odd. Are we again talking about *localization* here or *customer-specific terminology*. Because again, in the former case, caching makes a lot of sense. In the latter case, it doesn't, and neither does asking each customer to translate generic phrases into their own language.

Handling the latter via localization is a hack.

[Blama]

Hi Isomorphic,

You referred to a field name change again, but we think you actually meant field title again, right?

My bad, always meaning field title.

So to be clear on what you're asking: you're expecting that localized field titles change at runtime, even within the same locale? And this is why - because translations were actually added or updated for a locale?

This is my plan of action:

• Reduce my WAR-file count to the minimum number possible in 11.1/12.0 - that is a combined war for every customer that can live with the default field names plus one for every customer with special needs
• Reduce my WAR-file count to 1 in 12.1p
  • Introduce suffixed DataSources
  • Use LocaleMessageProvider
• Restart the application only if a new customer is onboarded or an application update is made

This means if I onboard a new customer and he or she changes the field titles, this change should be visible immediately (=meaning after a reload with a cache buster for DataSourceLoader (already have it for .ds.xml changes, just need to amend it)).
Most likely I'll have to restart the server to make it also serve the new customer's subdomain, but once it does and the user has the Admin account, he or she should be able to change field titles.

Do you realize that, even if new titles are available at the server, the application loaded into the browser won't change: the user will have to reload the page, and depending on how things are configured, browser caching may mean they still see the older version of the DataSource, even on reload?

Yes, reload is fine and I can display a message "Please reload after doing changes to the titles in order to see an effect". But I can't display a message "Please wait until I choose to restart the application server".

Just seems odd that you would bother making things this dynamic. A web application restart doesn't take very long, and the UI can handle the process very smoothly. Depending on how sessions are implemented, users that don't happen to make a request during the restart may not even notice that it happened.

Yes, your relogin mechanism is indeed pretty amazing :)

The only problem here if it were cached is that it's hard to tell for the customer when a change will come live and this is strange.

Best regards
Blama

[Isomorphic]

You referred to a field name change again, but we think you actually meant field title again, right?

So to be clear on what you're asking: you're expecting that localized field titles change at runtime, even within the same locale? And this is why - because translations were actually added or updated for a locale?

Do you realize that, even if new titles are available at the server, the application loaded into the browser won't change: the user will have to reload the page, and depending on how things are configured, browser caching may mean they still see the older version of the DataSource, even on reload?

Just seems odd that you would bother making things this dynamic. A web application restart doesn't take very long, and the UI can handle the process very smoothly. Depending on how sessions are implemented, users that don't happen to make a request during the restart may not even notice that it happened.

[Blama]

Hi Isomorphic,

Yes, using Dynamic DataSources without suffixing but with pooling off would also be expected to work, but would have pretty bad performance. You would be forcing the system to parse and interpret DataSource files for every DataSource interaction.

OK, thanks. Then it is the suffixed and pooled version for me, before I start having different DS per customer.

LocalMessageProvider does not allow for fieldName changes at runtime. It gives you a way to provide i18n strings embedded in DataSources. Probably you just mispoke here.

Yes. I meant field title.

E.G.: Resulting field (with or with DSGenerator) is
<field name="STATUS_RESELLER_ID" type="integer" displayField="STATUS_RESELLER_NAME">
            <title><fmt:message key="reseller"/></title>
            <validators>
                <validator type="isUnique" serverOnly="true">
                    <errorMessage><fmt:message key="validatorNameInUse" /></errorMessage>
                </validator>
            </validators>
</field>

This will then always be run through LocaleMessageProvider (if defined), when the complete DataSource is needed, e.g. for a DatasourceLoader call or when generating validation errors, correct?

The docs don't currently define a lifecycle here, and it seems perfectly valid to assume that the same string in the same locale has the same translation, and cache based on that. This would break any plan of using the i18n system to do per-customer terminology changes, instead of its designed role as a localization system.

Yes - for this to work per customer we'd need suffixed DataSources - having this is the plan before switching to 12.1 once it is a "p" version.
The only remaining question then is what to do in case of runtime field name changes, which I assume are not that often. This is only a problem if you do cache fmt results which you say do don't, correct?
Actually in the thread leading to the feature sponsorship this was kinda a requirement, even if not put into writing:

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.

It's unlikely that you would need to configure the pool size unless you had many thousands of customers on a server with unusually constrained memory. But feel free to play with it and find the best settings for you.

Thanks - just asking to be sure. Not to have to change anything is always the best.


Best regards
Blama

[Isomorphic]

IMHO it should also work without dynamic DS with suffix, if one disables pooling. But this will have a performance impact. Both correct?

Yes, using Dynamic DataSources without suffixing but with pooling off would also be expected to work, but would have pretty bad performance. You would be forcing the system to parse and interpret DataSource files for every DataSource interaction.

Here I had a second thought. IMHO caching is not an option for you, because the feature built in 12.1 should allow for fieldname changes at runtime.

LocalMessageProvider does not allow for fieldName changes at runtime. It gives you a way to provide i18n strings embedded in DataSources. Probably you just mispoke here.

So the developer can cache the names from the DB (e.g. in a singleton or in the session) in order to save lookup time, but you must run (pooled) DataSources always through a LocaleMessageProvider, if defined. Is this assumption correct?

The docs don't currently define a lifecycle here, and it seems perfectly valid to assume that the same string in the same locale has the same translation, and cache based on that. This would break any plan of using the i18n system to do per-customer terminology changes, instead of its designed role as a localization system.

It's unlikely that you would need to configure the pool size unless you had many thousands of customers on a server with unusually constrained memory. But feel free to play with it and find the best settings for you.

[Blama]

Hi Isomorphic,

all agreed.
To have different .ds.xml and pooling, one needs dynamic DS with suffix. This is the suggested best practice and my long term goal.

IMHO it should also work without dynamic DS with suffix, if one disables pooling. But this will have a performance impact. Both correct?

It would break if, for example, we took the completely reasonable measure of caching translations per-locale.

Here I had a second thought. IMHO caching is not an option for you, because the feature built in 12.1 should allow for fieldname changes at runtime. So the developer can cache the names from the DB (e.g. in a singleton or in the session) in order to save lookup time, but you must run (pooled) DataSources always through a LocaleMessageProvider, if defined. Is this assumption correct?


Thinking about it, another question came into my mind: In a multi home environment, where all DS are dynamic and dynamic DS are pooled, can / should one configure the pool size? Because the number of DataSources can potentially be HUGE.
I see there is a section "Generic pooling config" in isomorphic_core_rpc.jar/framework.properties.
(The link in the file is dead and should be replaced by this one).

Best regards
Blama

[Isomorphic]

OK, but what would be an non-hackish solution worth the necessary effort to the task in your opinion, if the application is the same otherwise?

No idea what the question is here.

To restate: if you use the i18n system to do something that's non-i18n, expect future breakage.

If there is customer-specific terminology - or anything customer specific that you are placing in a .ds.xml file - then you would need to use Dynamic DataSources and suffixing. Just for completeness: this yet again does not imply any need to turn off pooling.

And for completeness for any other readers: the use case of customer-specific terminology does not require using Dynamic DataSources. The different terms could simply be stored as field values instead of appearing directly in the .ds.xml files. Blama just happens to have chosen to implement this via Dynamic DataSources.

[Blama]

Hi Isomorphic,

Those are not translations into a different language, they are industry-specific terminology. It would be a hack to use a system intended for localization to implement industry-specific terminology instead.

OK, but what would be an non-hackish solution worth the necessary effort to the task in your opinion, if the application is the same otherwise?

It would break if, for example, we took the completely reasonable measure of caching translations per-locale.

That it exactly why I asked. If you cached, I'd need to use suffixed DataSources, and this would work, because the terminology is constant per customer.

Best regards
Blama

[Isomorphic]

Those are not translations into a different language, they are industry-specific terminology. It would be a hack to use a system intended for localization to implement industry-specific terminology instead. It would break if, for example, we took the completely reasonable measure of caching translations per-locale.

[Blama]

Hi Isomorphic,

yes, I fully agree, but unfortunately that's the way it is.
We are distributing leads. Depending on the industry the person taking a lead is:

• a "Reseller" (IT industry) (German: "Reseller", "Partner")
• a "Dealer" (HVAC, Sanitary, Automobile industry) (German: "Händler")
• a "Broker" (Insurance) (German: "Makler")

Depending on the customer a campaign can be named "campaign" or "source". A lead can be named "lead" or "inquiry". And so on and so forth.

In order to make transition as easy as possible for our customer and their partners (whatever they are called), we try to stay as close to the customer wording as possible. Also, often the persons using our software are not too fond of IT, so we have to do our best to be as flexible as possible and give as little reason as possible to object the change of process.

Best regards
Blama