nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CSIDE 10.5 BuildOspace Problem on Startup

Chris Meyer

In CSIDE10.5 the BuildOspace() call was added to the module Startup() function. It goes like this:

Object globals = $MyModule = .Globals.Initialize()

Within Initialize() it calls:

newGlobals.BuildOSpace()

Within BuildOSpace() it calls

.SubclassBuildOSpace()

Within SubclassBuildOSpace() I do a bunch of things to setup my module and do so by referencing $MyModule. The problem is $MyModule isn't defined yet since it's only assigned after Initialize() returns. I know I could fix this with a fully qualified object reference, but I need to maintain backwards compatibility with older version of Content Server. Is this a bug? Any workarounds?

Find more posts tagged with

Comments

Mark_Sherry

Actually, using a fully qualified name here wouldn't be right, since that would be modifying the non-temp object, rather than the temp that gets bound to $MyModule.

Fortunately, inside SubclassBuildOSpace you should be able to refer to the temp object that will end up getting bound to $MyModule by this. If, for backwards compatability reasons, you need to be able to run the script on the non-temp object as well, you could first check for the existance of MyModule and use it if available. E.g.

Object thisModule if isDefined( $MyModule ) thisModule = $MyModule else // Currently running start-up thisModule = this end thisModule.whatever

David Templeton

Chris

How are you intending to maintain backward compatibility? Do you intend on compiling on 10.5 and expecting to work on 10? Or do stuff on 10 still and run the binary on 10.5?

David

Chris Meyer

Hi Mark: Unfortunately this doesn't work since further underlying calls are made to functions that depend on $MyModule. I worked around it by overriding Globals.Initialize() to this (which is the same as CS10):

function Object Initialize()    return( OS.NewTemp( this ) )end

In the Root.Startup() I added this....

Object  globals = $MyModule = .Globals.Initialize()if $MyModule.OScriptUtils.IsCS105()    globals.BuildOSpace()end

It's a hack, but works. A related question: is it absolutely necessary to call BuildOSpace() on Startup? Or is it just a convenience for developers who forget to do it manually?

Another question: What's the best way to implement a method to check if we're on CS10.5? I hoped System.AppBuildNo() would help, but unfortunately that number is lower on CS10.5 than CS10U9.

Thanks.

Chris Meyer

Quoted David Templeton on 2014-02-27 00:03:

How are you intending to maintain backward compatibility? Do you intend on compiling on 10.5 and expecting to work on 10? Or do stuff on 10 still and run the binary on 10.5?

Hi David: The later. I plan to continue developing with Builder and testing with 10.5. Other than this problem with BuildOSpace() on Startup() it seems to be working.

Mark_Sherry

is it absolutely necessary to call BuildOSpace() on Startup? Or is it just a convenience for developers who forget to do it manually?

In CS 10.5, yes, since running scripts like BuildOSpace don't actually modify the source files from which the shipping OLLs are built. The alternative would be to have everybody maintain the list of objects to initialize by hand, which I suspect would be even less popular.

(I am aware that 3rd party developers don't currently have any tools for compilng OLLs from source other than through CSIDE, but I'm hoping we can fix that.)

Ferdinand Prantl

Did you say that you continue developing in the Builder? I'm also in the camp of "develop on CS10 and deploy on both 10 and 10.5". I don't have problems with the BuildOSpace. I'm calling it in the Builder before I finish the OLL or export the OSX files. Do you call the BuildOSpace (from the conetxt menu) after adding a new object for example?

Maybe the server could provide two events in the startup - like BeforeInitialize and AfterInitialize - and and the code needing the built objects would be moved to the latter?

Chris Meyer

Quoted Mark Sherry on 2014-02-28 21:29:

I see. However, I assume running BuildOSpace in CS10.5 on Startup isn't important when the module was built with CS10 Builder (and BuildOSpace was run on the source). This way the f__InitObjs will already be correctly initialized.

I have to find a workaround to referencing $MyModule in SubclassBuildOSpace() in CS10.5, and I'm leaning towards just removing the call to BuildOSpace() on Startup completely. I guess as long as I continue to develop with Builder I should be okay.

Chris Meyer

Quoted Ferdinand Prantl on 2014-02-28 21:36:

Yes. I continue to code with Builder while testing it with CSIDE10.5. My problem with BuildOSpace has to do with how CS10.5 calls BuildOSpace at startup, but does so before $MyModule is defined. This means I can't add custom code to SubclassBuildOSpace that references $MyModule, which is what I'm trying to find a workaround for.

Hans Stoop

Can’t you just assign this to $MyModule in your SubclassBuildOSpace?

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Freitag, 28. Februar 2014 21:46
To: eLink Recipient
Subject: CSIDE 10.5 BuildOspace Problem on Startup

CSIDE 10.5 BuildOspace Problem on Startup

Posted bychris.meyer@kwe.li (Meyer, Chris) On 02-28-2014 15:36

Quoted Ferdinand Prantl on 2014-02-28 21:36:

[To post a comment, use the normal reply function]
Topic:	CSIDE 10.5 BuildOspace Problem on Startup
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Chris Meyer

Quoted Hans Stoop on 2014-02-28 22:50:

Can’t you just assign this to $MyModule in your SubclassBuildOSpace?

Good idea, but we'd probably want to play it safe and revert the value after assigning it (we don't want to mess up the value if calling BuildOSpace manually). Something like this:

function Void SubclassBuildOSpace()    Dynamic myModuleOriginal = $MyModule    $MyModule = this    // do my stuff here    $MyModule = myModuleOriginalend

I'll give it a try - thanks!