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; } } }

Wrapscripts? Struggling with it...

DCX_Technical_(dcx_tech_-_(deleted))

Hi:I'm using customizationsRT to generate a modification of $WEBLL.LLRequestHandler.GetLoginprimarily to point the whole thing to a different fHTMLFile so that I can modify it transparently and upgradeably.I've been using Wrapscripts successfully for other RequestHandlers, but somehow I'm not having joy with the above LLRequestHandler.Any ideas? I could use other types of overrides, but I feel this is the cleanest way of modifying the system.Thanks,Rolf (livelink freelancer)PS: The script is at:$CustomizationsRT.UtilsRT.WrapScripts(this)

Find more posts tagged with

Comments

DCX_Technical_(dcx_tech_-_(deleted))

In case you want to email me rather - rolf@stasolutions.co.zaThanks,Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

It seems that for some reason Wrapscipts runs when the requesthandler hasn't been fully loaded yet. If I put a breakpoint in my __Init it seems to work fine. I added Echo ("Featurename = " + featureName)into the outer "for" loop of wrapscripts, and it doesn't seem to see any features at all on startup.Any help will be appreciated.Thanks again!Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

For some reason it doesn't seem to initiate wrapscripts at all!Oh well...Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

Solved!I just orphaned something from a module that gets loaded near the end.That way it seems everything is ready for wrapscripts to run...Regards,Rolf.

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

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

Hi Rolf,

I like to know the actual problem was.

Did you orphan the GetLogin request handler in your module? It may be an issue with the order of initialization.

Any idea what the value of the Object parent was in the wrapscripts function when it got called? Maybe I need to add some extra tests there.

In the customizationsRT there is also a Patch object. The nice thing of that object is that it does the patches/wrapscripts after the standard patches.

So it means that your changes will never be overwritten by Livelink patches and you will wrap the Livelink patches.

If you want to change the webLingo file you could also overwrite the .fHTMLFIle feature with wrapscripts. I know it sounds silly.

Or you could use the HTMLmap/modulemap functionality in CustomizationsRT to replace the login page. Then the login page will be replaced with a webLingo file in your own module. No need to change the original.

Hans

From: eLink Discussion: Livelink Builder Discussion [mailto:componentbuilder@elinkkc.opentext.com]
Sent: maandag 6 december 2004 20:37
To: eLink Recipient
Subject: Update

Update Posted by dcx_tech (Technical, DCX) on 12/06/2004 02:35 PM
In reply to: Update - Doesn't seem to initiate WrapScripts Posted by dcx_tech (Technical, DCX) on 12/06/2004 02:27 PM

Solved!

I just orphaned something from a module that gets loaded near the end.

That way it seems everything is ready for wrapscripts to run...

Regards,
Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

Hans:Thanks for your reply - here is some more info:- Yes I orphaned out the GetLogin requesthandler- I actually think wrapscripts doesn't run at all because customizationsRT isn't loaded at that point. It seems that if I orphan the root object of customizationsRT, it also loads correctly.- Overriding fHTMLFile is exactly what I'm trying to do - there's only so much one can do with Appearances... - I forgot about HTMLmap - will look into this as well...Do you need any more info?Regards,Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

Hans:I concur - the HTMLMap mechanism is probably better for what I'm trying to achieve here...MapLLVersion - core weblingo filesMapModule - module weblingo filesThanks again!Rolf.

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

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

Thanks Rolf,

It is clear to me that it is the initialization order. CustomizationsRT must be initialized first, because it sets $CustomizationsRT, which you use.

You influence the initialization order by orphaning objects. Livelink guarantees that the parent OSpace is initialized first.

Hans

From: eLink Discussion: Livelink Builder Discussion [mailto:componentbuilder@elinkkc.opentext.com]
Sent: dinsdag 7 december 2004 5:32
To: eLink Recipient
Subject: Details..

Details.. Posted by dcx_tech (Technical, DCX) on 12/06/2004 11:29 PM
In reply to: RE Update Posted by hstoop (Stoop, Hans) on 12/06/2004 06:18 PM

Hans:

Thanks for your reply - here is some more info:

- Yes I orphaned out the GetLogin requesthandler
- I actually think wrapscripts doesn't run at all because customizationsRT isn't loaded at that point. It seems that if I orphan the root object of customizationsRT, it also loads correctly.
- Overriding fHTMLFile is exactly what I'm trying to do - there's only so much one can do with Appearances...
- I forgot about HTMLmap - will look into this as well...

Do you need any more info?

Regards,
Rolf.

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

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

Rolf,

Mapmodules also handles core webLingo files. Just put them in the root of the mapmodules directory.

MapLLVersion is used when you want to map a HTML file in a module that supports 2 different Livelink versions and the webLingo is different between the 2 Livelibnk versions.

Hans

From: eLink Discussion: Livelink Builder Discussion [mailto:componentbuilder@elinkkc.opentext.com]
Sent: dinsdag 7 december 2004 6:16
To: eLink Recipient
Subject: HTMLMap a better option

HTMLMap a better option Posted by dcx_tech (Technical, DCX) on 12/07/2004 12:01 AM
In reply to: Details.. Posted by dcx_tech (Technical, DCX) on 12/06/2004 11:29 PM

Hans:

I concur - the HTMLMap mechanism is probably better for what I'm trying to achieve here...

MapLLVersion - core weblingo files
MapModule - module weblingo files

Thanks again!
Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

Hans:Thanks again - yes I noticed one can use MapModules for core weblingo files.The version capability of MapLLVersion is one reason why I might choose it though - the MapModules script obviously inherently takes care of different versions of modules.By the way MapLLVersion doesn't seem to work with AppearanceHTML. I haven't investigated it any further - let me know if you want me to look into it some more - you should be able to reproduce it quite easily. It might be important to check with the new 9.5 release that includes AppearanceHTML by default, so customers will probably be using it. Maybe integrate the MapNN scripts with AppearanceHTML somehow ? You decide :-) Regards,Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

A case of lack of RTFM on my part I guess - I made a note in my developers course's notes that say I should orphan the Root object.Thanks,Rolf.

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

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

Any object will do.

Hans

From: eLink Discussion: Livelink Builder Discussion [mailto:componentbuilder@elinkkc.opentext.com]
Sent: dinsdag 7 december 2004 12:13
To: eLink Recipient
Subject: Yup - orphaning Root from CustomizationsRT does the trick...

Yup - orphaning Root from CustomizationsRT does the trick... Posted by dcx_tech (Technical, DCX) on 12/07/2004 06:10 AM
In reply to: RE Details.. Posted by hstoop (Stoop, Hans) on 12/07/2004 03:05 AM

A case of lack of RTFM on my part I guess - I made a note in my developers course's notes that say I should orphan the Root object.

Thanks,
Rolf.

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

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

There are 3 mapping functions:

1. MapModules, this only requires you to create a module directory. Easy, but doesn't support module versions

2. MapDirectory, you need to create a module directory (incl. version) and the HTML directory.

3. MapLLVersion, does a mapping based on LL version. The webLingo files changed quitre a bit between LL 9.1 and 9.2, but the module versions didn't change.

I don't have a version of customizationsRT for 9.5 yet. But what goes wrong?

Can you check if $CustomizationsRT.fHTMLMaps contains your mapping? Are you sure you use the correct version nummers in your directory path.

You tested it with which LL version and which Appearance HTML version?

Hans

From: eLink Discussion: Livelink Builder Discussion [mailto:componentbuilder@elinkkc.opentext.com]
Sent: dinsdag 7 december 2004 12:13
To: eLink Recipient
Subject: HTMLMap...

HTMLMap... Posted by dcx_tech (Technical, DCX) on 12/07/2004 06:08 AM
In reply to: RE HTMLMap a better option Posted by hstoop (Stoop, Hans) on 12/07/2004 03:26 AM

Hans:

Thanks again - yes I noticed one can use MapModules for core weblingo files.

The version capability of MapLLVersion is one reason why I might choose it though - the MapModules script obviously inherently takes care of different versions of modules.

By the way MapLLVersion doesn't seem to work with AppearanceHTML. I haven't investigated it any further - let me know if you want me to look into it some more - you should be able to reproduce it quite easily. It might be important to check with the new 9.5 release that includes AppearanceHTML by default, so customers will probably be using it. Maybe integrate the MapNN scripts with AppearanceHTML somehow ? You decide :-)

Regards,
Rolf.

DCX_Technical_(dcx_tech_-_(deleted))

Hans:I'm using MapLLVersion in this case, with Livelink 9.2SP1 and AppearanceHTML 10.5. I see the following in the debug window when Builder starts up:MapLLVersion: SA LUG Customisationhtmlmap: Mapping file C:\OPENTEXT\module\custsalug_1_0_1\html\llglogin.html to C:\OPENTEXT\module\custsalug_1_0_1\html\9\2\llglogin.htmlSo that would explain it - it's not overriding the core weblingo file, its simply mapping it to the module's html directory based on the version number of Livelink.I just misunderstood the function of the script then - my apologies.Regards,Rolf.

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

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

You are right. MapLLVersions allows you to have your own module run in different LL versions, without the need to have multiple versions of your module.

Hans

From: eLink Discussion: Livelink Builder Discussion [mailto:componentbuilder@elinkkc.opentext.com]
Sent: dinsdag 7 december 2004 13:16
To: eLink Recipient
Subject: MapLLVersion Details

MapLLVersion Details Posted by dcx_tech (Technical, DCX) on 12/07/2004 07:15 AM
In reply to: RE HTMLMap... Posted by hstoop (Stoop, Hans) on 12/07/2004 06:44 AM

Hans:

I'm using MapLLVersion in this case, with Livelink 9.2SP1 and AppearanceHTML 10.5.

I see the following in the debug window when Builder starts up:

MapLLVersion: SA LUG Customisation
htmlmap: Mapping file C:\OPENTEXT\module\custsalug_1_0_1\html\llglogin.html to C:\OPENTEXT\module\custsalug_1_0_1\html\9\2\llglogin.html

So that would explain it - it's not overriding the core weblingo file, its simply mapping it to the module's html directory based on the version number of Livelink.

I just misunderstood the function of the script then - my apologies.

Regards,
Rolf.