Why should the Multilingual Check function always return True?
Hi,
We want the browse folder functionality to avoid having the sql query join with the webnodes_metadata_EN_en table. This woud improve our browsing experience tremendously.
To achieve this there is a configuration setting, however this is always overruled in the Oscript function '_GetSelectWithPaging_IsMultiplingual' referring to some 'default colation' that should be in place. The function always returns a true value regardless of the configuration setting.
Can anyone give an insight what the logic is behind this?
What colation is it referring to here?
Is it okay that we comment out this line in a patch? or will something fall apart?
Best Answers
-
K, I do see that this bit of code did in fact get removed in 24.4 in a fix named "Poor performance of Name filter on SmartUI browse for large folders".
So @SanderH_Achmea it sounds like we fixed an issue very similar to what you mentioned in your first post ;-)
@siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you
1 -
So it seems, upgraded my environment to latest available, V 24.3, and the code is still there.
So I guess we will wait till 24.4 is released.
1 -
So doesn't look like an easy fix.
The fix coming out in 24.4 is not trivial - I'm not surprised this caused issues.
Can it be confirmed this will be addressed as well in V24.4?
If I read your question correctly you're asking "is the crash I introduced by customizing a function in the shipped product going to be fixed i the next release?". I don't think anyone can confirm something like that.
Further / to be 100% clear: I cannot confirm that the initial problem you reported will be fixed in 24.4 - I can only state that that section of code has been reworked, and the snippet I provided in comment #6 looks to be what will be in product in the next release.
@siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you
0
Answers
-
You might force a reply by writing to support . Usually, they won't but if you persevere they might. I have not been doing much on Oscript these days nor do I work in multilingual however I will tag a few Oscripters I know
@Hugh_Ferguson ,(Christopher Meyer-https://www.linkedin.com/in/chriscdn/?originalSubdomain=ch)
Alex Kowalenko (https://www.linkedin.com/in/kowalenko/) (Alex 's company Cassia is a big vendor of Multi Lingual Modules
At some point when OT moved to CSIDE(Builder's new avatar ) there was some move to make things Private(meant internal) so when you are in the Oscript pane does this feature or Documentation allow you to override it?
0 -
Hi @SanderH_Achmea - where did this function come from, and what version of Content Server are you running with?
I just did a super-quick check on my system, and I couldn't find the snippet you took a screen shot of.@siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you
0 -
Ignore the above - I cut & pasted what you typed above, which was "_GetSelectWithPaging_IsMultiplingual" (not "._GetSelectWithPaging_IsMultilingual") . Spelling it correctly allowed me to search things a wee bit quicker ;-)
Here's what I have in the unadulterated codebase for 24.x:
/**
* @private
*
* Returns if the current system is a monolingual or multilingual to allow the optimization
* of the the browse SQL
*
* @param {Object} dapiCtx
*
* @return {Boolean}
*/
private function Boolean _GetSelectWithPaging_IsMultilingual( Object dapiCtx )
Assoc checkVal
Boolean isMultilingual = FALSE
Object prgCtx = dapiCtx.fPrgCtx
checkVal = $LLIAPI.LanguagePkg.IsMultilingual( prgCtx )
if ( checkVal.ok == TRUE )
isMultilingual = checkVal.isMultilingual
end
return isMultilingual
end
… so I'm guessing that you're dealing with a customization, or this is something that's changed between your version & the latest thing we ship.@siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you
1 -
Yes sometimes if it is the advanced customizations route(The great Chris Webster & Hans Stoop kind) the code that one views will be overridden by the module . Usually, the prior developers will have some mechanism to show the world the original object is overridden. If nothing else removing any custom modules /patches should reveal the original OT implementation.
0 -
I am in Eclipse environment using a 23.3 version of CS
0 -
Hi David, sorry for the typo. Was not able to copy/past the name at that time.
So this override is not present in the 24.x versions? I will upgrade my environment the and check
0 -
Hi Sander,
I can confirm that in 24.1 the following lines are still there.
// default to true until the DTree.Name can be assigned the default collation
isMultilingual = TRUEHans
3 -
K, I do see that this bit of code did in fact get removed in 24.4 in a fix named "Poor performance of Name filter on SmartUI browse for large folders".
So @SanderH_Achmea it sounds like we fixed an issue very similar to what you mentioned in your first post ;-)
@siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you
1 -
So it seems, upgraded my environment to latest available, V 24.3, and the code is still there.
So I guess we will wait till 24.4 is released.
1 -
Hi,
To follow up on this I thought I would create the patch anyway for now. Seemed like a quick fix to just comment out the "isMultilingual = TRUE".
However this causes the browse action to crash when browsing classifications (Enterprise → Classifications).
As far as I can see this issue would need to be solved in below function where as the code tries to reconstruct the sql to a correct the malformed syntax but fails.
So doesn't look like an easy fix.
Are there other browse actions where this issue might popup?
Can it be confirmed this will be addressed as well in V24.4?
regards,
Sander
"
0 -
So doesn't look like an easy fix.
The fix coming out in 24.4 is not trivial - I'm not surprised this caused issues.
Can it be confirmed this will be addressed as well in V24.4?
If I read your question correctly you're asking "is the crash I introduced by customizing a function in the shipped product going to be fixed i the next release?". I don't think anyone can confirm something like that.
Further / to be 100% clear: I cannot confirm that the initial problem you reported will be fixed in 24.4 - I can only state that that section of code has been reworked, and the snippet I provided in comment #6 looks to be what will be in product in the next release.
@siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you
0
Categories
- All Categories
- 123 Developer Announcements
- 54 Articles
- 150 General Questions
- 148 Thrust Services
- 57 OpenText Hackathon
- 37 Developer Tools
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 918 Core Messaging
- 84 Digital Asset Management
- 9.4K Documentum
- 32 eDOCS
- 186 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 8 XM Fax
- Follow Categories