Dynamic Xlates

Hi,

When building dynamic UI elements, i.e. elements that can change due to config, is there any way to generate Xlates on the fly? That is instead of pulling the entry from the properties file, it pulls the appropriate translation from the database? I know the metadata ML tables exist for doing that with object names, but I'm thinking more of the various menus, for instance if you added a new menu item, or a new menu. Right now, for instance, the menu building subsystems update $WebLL.WebUtils.fMenu with the menu ID and the xlate string, and then on the individual server in the cluster, it substitutes in what you have in the properties file for that menu. I'm looking at a way of being able to dynamically allocate menus (not just add menu items to the Enterprise menu) but the stumbling block is how to manage translations. I'm working for the Canadian government so being bilingual is critical. I'm wondering if any other developers have tried to tackle this.

-Hugh Ferguson

Find more posts tagged with

Comments

Benjamin Shapiro

The Multilingual Module for Content Server provides the ability to give translations to additional Enterprise Menu items, as well as a whole host of additional multilingual features of interest to the Canadian government, such as:
- attribute multilingualization (names, values, facets, columns)
- dynamic search translation
- report multilingualization
- multilingual Workflow (steps, descriptions, etc.)
- content translation
.. and more!

Cheers,
Ben

On 2016-10-13 2:43 PM, eLink Entry: Content Server Development Forum wrote:

eLink : Dynamic Xlates
Dynamic Xlates Posted by Ferguson, Hugh On 10/13/2016 02:32 PM

Hi, When building dynamic UI elements, i.e. elements that can change due to config, is there any way to generate Xlates on the fly? That is instead of pulling the entry from the properties file, it pulls the appropriate translation from the database? I know the metadata ML tables exist for doing that with object names, but I'm thinking more of the various menus, for instance if you added a new menu item, or a new menu. Right now, for instance, the menu building subsystems update $WebLL.WebUtils.fMenu with the menu ID and the xlate string, and then on the individual server in the cluster, it substitutes in what you have in the properties file for that menu. I'm looking at a way of being able to dynamically allocate menus (not just add menu items to the Enterprise menu) but the stumbling block is how to manage translations. I'm working for the Canadian government so being bilingual is critical. I'm wondering if any other developers have tried to tackle this. -Hugh Ferguson
[To post a comment, use the normal reply function]
Forum: Content Server Development Forum
Content Server: Knowledge Center CS16

Chris Meyer

Hi Hugh, it's possible to dynamically change the value of an xlated string to reflect a value in the database or anywhere else. However, it's not straightforward and requires:

writing the translated values to the filesystem (in the format of an xlate .properties file), reading the file into Content Server (using an XLate method), and deleting the file;
repeating for each language; and
keeping changes synchronised among servers and threads (possible by using $LLIAPI.ThreadCache).

HFCDev

Quoted Ben Shapiro on 10/14/2016 10:09 AM:

Hi Ben,

I'd love them to get on board with EMLC, but I'm looking at adding additional menu items. If it won't fly, it won't fly, but I'm going to push the state of the art to its logical extreme

-Hugh

HFCDev

Hi Chris,

I found where I *could* do this, although I'm going to suggest to my client that they not pursue it. The menus stored in $WebLL.WebUtils.fMenu are xlate keys. I could do a substitution for my dynamic menus in $WebLL.LivelinkNavigationCB.Items() where it gets each new menu header. First off, that would be an override of a core function, but second all, I would definitely need a prgCtx. I've noticed that the LivelinkNavigationCB and LivelinkGCNavCB Execute methods, although they take a prgCtx, one is not always on offer, leaving you to get it from the request object and even then, it may not be present. If you have no prgCtx you can neither query the database for your config, nor do you have the user's language preference to do a substitution.

I'm guessing that this is part of the reason why additional Enterprise menus are stored in the opentext.ini file and not in KINI or another table

-Hugh

Chris Meyer

Hi Hugh: You don't need to do any substitutions per se. I thought you were asking how to change what an XLATE maps to for each language. This is what I was trying to answer in my previous reply. The approach lets you define an arbitrary XLATE (e.g., [MYMODULE_LABEL.HELLO]) and configure (e.g., via the UI) what this value maps to for each language. You then create a temporary .properties file with your dynamic values and force Content Server to reload from that file.

Here's the thing: The loading of custom XLATE values need only be done once per thread. Once it's loaded you're done and CS will continue to use the values for all remaining requests on that thread. Only if the XLATE values change do you need to load the values again (which I handled with $LLIAPI.ThreadCache). So it doesn't matter if a prgCtx isn't available: Once it becomes available you can load the custom strings and you're done (which can be done in a $LLIAPI.ThreadCache subclass instead of a navigation menu callback).

HFCDev

I was hoping for something that would work in a cluster. This solution requires the new properties to be written to each server in the cluster. Our PRD environment has 6 front-end and 3 back end servers.

-Hugh

Chris Meyer

Hi Hugh,

I was hoping for something that would work in a cluster.

Have a closer look at $LLIAPI.ThreadCache. This can be used to keep values synchronized among all servers and threads.

John Simon

Uh oh, just when I think I have the cache thing figured out I hear about another one. We've got Kini (which has a caching system), SystemData, LLCache, Memcached, and now ThreadCache. I think I have seen a page of documentation on when you should use each...ex: Kini is write seldom/read often. Anybody have a reference to that or know which situation is best for each?

Cheers...

Chris Meyer

Hi John: I started a blog post on this once, but never got it passed a draft state. Let me give you a quick summary:

KIni - Stores a value against a pair of keys (IniSection & IniKeyword). Any serialisable datatype can be persisted (e.g., can be cast to a string and back). Values are automatically cached per thread for optimal performance. It should be used for values that change infrequently since updates force a cache refresh on each thread.
LLSystemData - More or less the same as KIni, but without caching.
LLCache - Used to store transient data in the database. When storing data you get back an integer (sort of like a coat check ticket), which you can later use to retrieve the data (typically in a second request). Only serialisable data can be written to LLCache, and stale data is eventually purged by the agents.
Memcached - A distributed least recently used (LRU) cache, which is shared among all threads (i.e, thread A can write a value and thread B can read it). The original memcached interface is key-pair, but the CS implementation extends it to a pair of keys (namespace & key). Memcached should only be used for performance caching (i.e., to cache the results of a slow deterministic operation). It should never be assumed a cached value exists since it may have been purged. Only serialisable datatypes can be stored.
ThreadCache - A cache that exists in each thread (in memory). A ThreadCache instance contains code to return a value, which is stored and returned on each subsequent call. This is repeated in each thread. If a cached value becomes invalid it can be expired, which forces the value to be refreshed in each thread. Behind the scenes this works by storing a cache state in KIni (which implies a ThreadCache shouldn’t change often). Since it’s a memory cache any datatype (including objects, scripts, and frames) can be cached.

In a nutshell: KIni & LLSystemData is for persisting data (e.g., configuration values). LLCache, Memcached, and ThreadCache is for transient values. LLCache is usually used to store data between requests, while Memcached and ThreadCache is for performance.

Each has their advantages and uses, but sometimes they don’t suffice. I wrote a memory LRU cache since I needed something that was fast, didn’t depend on a prgCtx, and could store any datatype. I also extended memcached such that I can expire all entries for a given namespace or key. These have been quite useful for increasing performance in my modules.

eLink User

Thanks Chris for a great explanation.Maybe you should write that blog...

..... appnair appunair( Livelink Rocks )

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Tue, Oct 18, 2016 at 3:18 PM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

Dynamic Xlates Posted byMeyer, ChrisOn 10/18/2016 04:13 PM

Hi John: I started a blog post on this once, but never got it passed a draft state. Let me give you a quick summary: KIni - Stores a value against a pair of keys (IniSection & IniKeyword). Any serialisable datatype can be persisted (e.g., can be cast to a string and back). Values are automatically cached per thread for optimal performance. It should be used for values that change infrequently since updates force a cache refresh on each thread. LLSystemData - More or less the same as KIni, but without caching. LLCache - Used to store transient data in the database. When storing data you get back an integer (sort of like a coat check ticket), which you can later use to retrieve the data (typically in a second request). Only serialisable data can be written to LLCache, and stale data is eventually purged by the agents. Memcached - A distributed least recently used (LRU) cache, which is shared among all threads (i.e, thread A can write a value and thread B can read it). The original memcached interface is key-pair, but the CS implementation extends it to a pair of keys (namespace & key). Memcached should only be used for performance caching (i.e., to cache the results of a slow deterministic operation). It should never be assumed a cached value exists since it may have been purged. Only serialisable datatypes can be stored. ThreadCache - A cache that exists in each thread (in memory). A ThreadCache instance contains code to return a value, which is stored and returned on each subsequent call. This is repeated in each thread. If a cached value becomes invalid it can be expired, which forces the value to be refreshed in each thread. Behind the scenes this works by storing a cache state in KIni (which implies a ThreadCache shouldn’t change often). Since it’s a memory cache any datatype (including objects, scripts, and frames) can be cached.In a nutshell: KIni & LLSystemData is for persisting data (e.g., configuration values). LLCache, Memcached, and ThreadCache is for transient values. LLCache is usually used to store data between requests, while Memcached and ThreadCache is for performance.Each has their advantages and uses, but sometimes they don’t suffice. I wrote a memory LRU cache since I needed something that was fast, didn’t depend on a prgCtx, and could store any datatype. I also extended memcached such that I can expire all entries for a given namespace or key. These have been quite useful for increasing performance in my modules.
[To post a comment, use the normal reply function]Topic:Dynamic XlatesForum:Content Server Development ForumContent Server:Knowledge Center CS16