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

TeamSite Server Name in DCT

cliffhanger

What I am trying to do is call a common JS file that sits in a non-conventional area(some place other than /httpd/iw/...). So, to access a file there I would have to give the script src path as "http://servername:8080/directory/common.js".

<script language = "javascript" location = "webserver" src="http://servername:8080/someDIR/common.js"/>

Is there a way to get the servername in the DCT so that I can avoid hardcoding the name?

Find more posts tagged with

Comments

jbonifaci

Well, you could use an inline... but can't you also just use a relative path without the server name?

cliffhanger

can't you also just use a relative path without the server name?

using a relative path assumes the path to be under iw-home/httpd/..., so does not really work for me since this file will not be under httpd.

I guess I could use an inline, but I think I would rather try to convince the team that these common files should be under httpd/iw/

alignment.rptdesign

Adam Stoller

If the JS is stored in TeamSite - you could use a file system path - like:

<script location="webserver" src="/iw-mount/default/main/www/STAGING/formapi/myfuncs.js"/>

I'm not sure if you could use a regular file system path like "/var/tmp/myfunc.js" - but that might work too.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

cliffhanger

It *needs* to be stored in iw-home.

So, back to my original question: "is it possible to retrieve the TS servername in DCT?" The answer is NO, not unless somebody is willing to put in the effort to make some callout for that.
That's what I thought.....

Thanks folks for your input!

-cliff

LooseCannon

I'm pretty sure the answer is yes...

Write a perl script that gets the server name and prints out your js script tag. Call the perl script as an inline placed in the DCT where you want the <script> tag created.

cliffhanger

The answer is NO, not unless somebody is willing to put in the effort to make some callout for that.

I guess I wasn't very clear about what I meant by "that". I meant the <script> tag by that here...

Write a perl script that gets the server name and prints out your js script tag. Call the perl script as an inline placed in the DCT where you want the <script> tag created.

So the answer is no(without an inline script)

LooseCannon

you're right the answer is no, unless your willing to spend 30 min of your time to write the inline

jbonifaci

Well, having an additional inline is a performance hit, so I wouldn't recommend it. I would just make them put their js's under /iw. Just create a folder beneath with a more descriptive name.

~Jeff

LooseCannon

I think you have some serious hardware issues to address if an inline, that simply retrieves the server name and prints out one line of text, raises a concern related to performance.

jbonifaci

Just because you can, doesn't mean you should. That line of reasoning justifies writing inefficient code because your system can handle it. Each additional perl process you need to spawn for inlines adds to the load time. One here, one there, they add up. It is better to use as few as possible.

~Jeff

cliffhanger

Plus, you have to invoke this <inline> in every DCT where you want to use a common JS file.

Why create some unnecessary maintenance headche when it can be simply solved by choosing a different (and better) file location?

LooseCannon

You're comparing apples to oranges. Writing code to meet a technical need that happens to use up a few resources is a bit different then being lazy and writing junk code.

jbonifaci

Not really... Both eat up system resources that aren't needed. Bad code design or bad architecture, same thing IMO.

LooseCannon

cliffhanger wrote @ 6:45

In reply to:

It *needs* to be stored in iw-home.

cliffhanger wrote @ 1:02

In reply to:

Why create some unnecessary maintenance headche when it can be simply solved by choosing a different (and better) file location?

Your statements are conficting...

I’m not arguing against relocating the js file to the backing store. That’s the easiest way to go.

Clarification: With the inline solution you still use the js file. The inline just prints out its location which ultimately solves your dilemma of hard coding the server name

cliffhanger

You did not follow the entire thread carefully. You just picked up on my response to fish, which was in context to his suggestion or keeping the file under /iwmnt....

MY original post mentions What I am trying to do is call a common JS file that sits in a non-conventional area(some place other than /httpd/iw/...).

It *needs* to be stored in iw-home.

Why create some unnecessary maintenance headche when it can be simply solved by choosing a different (and better) file location?

I never said relocation to iw-store, so my these two statements are not really conflicting...

Anyway, I got my team convinced that this JS should reside in /httpd/iw/

Thank you guys!! I think we really should end this thread here...my issue's solved...haha