Editting Xlates programmatically?

We have some functionality that allows admins to edit a subgroup of xlates programmatically (from a link off of the admin page). This works fine in builder, but when when we run it outside of builder we get a variety of errors, everything from 'server did not respond', to no error, but no change either. Furthmore, from that point on subsequent calls to our module's XDB don't execute - we get weblingo pages with w/Xlate constants instead of text. Has anybody tried to do this/seen this/worked around it? I'm wondering if there is a notion of 'locking' of an XDB, and if so, if there is a way to programmatically unlock it when our module is started up. ThanksDawn Lambethdawn@vizdom.com

Find more posts tagged with

Comments

eLink User

Message from Andrew Foti <<A HREF="mailto:afoti@opentext.com">afoti@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

Hi,

I have recently experimented with dynamically changing the values of xlates this way:

function void LLFont_Set(string newFont)

String  xlation = Undefined
string  groupName="WebDsp_Font"
string   stringName="SansSerif"

if $XLateUtils.IsXlation( groupName, stringName )
$XLateUtils.GetXlateGroup( groupName ).( stringName ) = newFont
end

end

This is not changing the original xlate, it is changing the memory value for the current thread only - at restart, the change is lost. It is applied immediately but of course, there are several other threads out there which still have the original value - you would need to change this for all other threads, probably by reading the new value mapping from an ini file at restart of services. I tested this as a service and it worked ok. I have never done this in production so your mileage may vary.

Regards

Andrew Foti

-----Original Message-----
From: knowledge@opentext.com [mailto:knowledge@opentext.com]On Behalf Of eLink Discussion: Development Discussion
Sent: Tuesday, 14 May 2002 8:18 AM
To: eLink Recipient
Subject: Editting Xlates programmatically?

Editting Xlates programmatically? Posted by VIZDOMAdmin on 05/13/2002 06:16 PM

We have some functionality that allows admins to
edit a subgroup of xlates programmatically (from a link off of the admin page). This works fine in builder, but when when we run it outside of builder we get a variety of errors, everything from 'server did not respond', to no error, but no change either. Furthmore, from that point on subsequent calls to our module's XDB don't execute - we get weblingo pages with w/Xlate constants instead of text. Has anybody tried to do this/seen this/worked around it? I'm wondering if there is a notion of 'locking' of an XDB, and if so, if there is a way to programmatically unlock it when our module is started up.

Thanks
Dawn Lambeth
dawn@vizdom.com

eLink User

Message from Dave Kerrigan via eLinkIf you were to call this method from e.g. the startup script in your modulethen it would be set for all threads since each thread goes through the sameinitialisation process - just put a few 'echo()' in your script and you willsee this in each thread log.Dave Kerrigan====Message from Andrew Foti via eLinkHi,I have recently experimented with dynamically changing the values of xlatesthis way:function void LLFont_Set(string newFont) String xlation = Undefined string groupName="WebDsp_Font" string stringName="SansSerif" if $XLateUtils.IsXlation( groupName, stringName ) $XLateUtils.GetXlateGroup( groupName ).( stringName ) = newFont endendThis is not changing the original xlate, it is changing the memory value forthe current thread only - at restart, the change is lost. It is appliedimmediately but of course, there are several other threads out there whichstill have the original value - you would need to change this for all otherthreads, probably by reading the new value mapping from an ini file atrestart of services. I tested this as a service and it worked ok. I havenever done this in production so your mileage may vary.RegardsAndrew Foti-----Original Message-----From: knowledge@opentext.com [mailto:knowledge@opentext.com]On Behalf OfeLink Discussion: Development DiscussionSent: 14 May 2002 02:06To: eLink RecipientSubject: RE Editting Xlates programmatically?

eLink User

Message from Hans Stoop <<A HREF="mailto:hstoop@opentext.com">hstoop@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

It will all depends on how Livelink does its caching and how the order of initialization is.

I'm also wondering if the Livelink patching method will work for xlates as well. Because it are some kind of OSpaces.

Hans

--------
Livelink Appearance: the best way to skin Livelink.
Contact hstoop@opentext.com for more information.

-----Original Message-----
From: knowledge@opentext.com [mailto:knowledge@opentext.com]On Behalf Of eLink Discussion: Development Discussion
Sent: dinsdag 14 mei 2002 10:27
To: eLink Recipient
Subject: RE RE Editting Xlates programmatically?

RE RE Editting Xlates programmatically? Posted by eLink on 05/14/2002 04:27 AM
In reply to: RE Editting Xlates programmatically? Posted by eLink on 05/13/2002 09:05 PM

Message from Dave Kerrigan <dkerrigan@opentext.com> via eLink

If you were to call this method from e.g. the startup script in your module
then it would be set for all threads since each thread goes through the same
initialisation process - just put a few 'echo()' in your script and you will
see this in each thread log.

Dave Kerrigan

====
Message from Andrew Foti <afoti@opentext.com> via eLink

Hi,
I have recently experimented with dynamically changing the values of xlates
this way:

function void LLFont_Set(string newFont)
String xlation = Undefined
string groupName="WebDsp_Font"
string stringName="SansSerif"

if $XLateUtils.IsXlation( groupName, stringName )
$XLateUtils.GetXlateGroup( groupName ).( stringName ) = newFont
end
end

This is not changing the original xlate, it is changing the memory value for
the current thread only - at restart, the change is lost. It is applied
immediately but of course, there are several other threads out there which
still have the original value - you would need to change this for all other
threads, probably by reading the new value mapping from an ini file at
restart of services. I tested this as a service and it worked ok. I have
never done this in production so your mileage may vary.

Regards
Andrew Foti

-----Original Message-----
From: knowledge@opentext.com [mailto:knowledge@opentext.com]On Behalf Of
eLink Discussion: Development Discussion
Sent: 14 May 2002 02:06
To: eLink Recipient
Subject: RE Editting Xlates programmatically?

eLink User

Message from Dave Kerrigan via eLinkThe way that I've done overriding of xlates before was to call e.g.: $Kernel.XLateUtils.SetXlation('Home_HTMLLabel','Favorite','Fastpath')I did encounter problems with some kind of locking of the xbds, and I seemto rembember trying to do this from within a __Init script, a startupscript, or an old style patch but had problems where it works fine inbuilder, and then as a service but if you install it on another instance itdoesn't work.The way that I did it in the end was to put these types of calls in theDoCustomStep method of the modules configure object so it gets run oninstallation.Dave====RE RE RE Editting Xlates programmatically? Posted by eLink on 05/14/200205:39 AMIn reply to: RE RE Editting Xlates programmatically? Posted by eLink on05/14/2002 04:27 AMMessage from Hans Stoop via eLinkIt will all depends on how Livelink does its caching and how the order ofinitialization is.I'm also wondering if the Livelink patching method will work for xlates aswell. Because it are some kind of OSpaces.Hans--------Livelink Appearance: the best way to skin Livelink.Contact hstoop@opentext.com for more information.

JohnL

Thanks everyone for your suggestions. Our situation is a little different than the scenarios listed above. Basically we have a group in our module's XDB that maps mime types to 'user friendly' text for displaying with documents, i.e. application/msword becomes "Word document". We've built an admin function (accessed of the main admin.index page) to allow users to change those text mappings - i.e. "Word document" becomes "A fabulous document", etc. We also allow them to create new mime types, delete text mappings they've defined, etc. So we couldn't place the code to change the Xlates in init methods. I did notice this morning, however, that in the XLateUtils there are OpenXDB, LockXDB and UnlockXDB functions. It's not clear to me how they are to be used, but they seem like a reasonable thing to investigate. Thanks again for your help. Dawn

eLink User

Message from Hans Stoop <<A HREF="mailto:hstoop@opentext.com">hstoop@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

Why can't you put the code in an init method?

You can store the mapping in a separate table and read the table and set the xlates during the init. The only gotcha is that you have to restart Livelink after a change.

Hans

--------
Livelink Appearance: the best way to skin Livelink.
Contact hstoop@opentext.com for more information.

-----Original Message-----
From: knowledge@opentext.com [mailto:knowledge@opentext.com]On Behalf Of eLink Discussion: Development Discussion
Sent: dinsdag 14 mei 2002 18:48
To: eLink Recipient
Subject: Thanks everyone for your suggestions. Our situation is a little different than...

Thanks everyone for your suggestions. Our situation is a little different than... Posted by VIZDOMAdmin on 05/14/2002 12:44 PM
In reply to: RE RE RE RE Editting Xlates programmatically? Posted by eLink on 05/14/2002 06:25 AM

Thanks everyone for your suggestions. Our situation is a little different than the scenarios listed above. Basically we have a group in our module's XDB that maps mime types to 'user friendly' text for displaying with documents, i.e. application/msword becomes "Word document". We've built an admin function (accessed of the main admin.index page) to allow users to change those text mappings - i.e. "Word document" becomes "A fabulous document", etc. We also allow them to create new mime types, delete text mappings they've defined, etc. So we couldn't place the code to change the Xlates in init methods. I did notice this morning, however, that in the XLateUtils there are OpenXDB, LockXDB and UnlockXDB functions. It's not clear to me how they are to be used, but they seem like a reasonable thing to investigate.
Thanks again for your help.

Dawn