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

Template components in DCTs?

jwl

Hi,
I am writing up a number of DCTs, many of which share common sets of checkboxes and select options.
I would like to put these into separate include files.
The only mechanism I can find for this is the "inline" tag.
However this seems to require a hard-coded reference to the include-file in the backing store, eg:
<inline command="/usr/bin/cat /default/main/LGO/WORKAREA/jlew/includes/interestAreas.inl"/>
This makes the workarea not very portable.
By contrast, component templates in PTs are referenced within the workarea root directory, making them portable.
Is there a way around this, or is there another component mechanism I can use for DCTs?
I am using TS 5.5.2.
Many thanks!

Find more posts tagged with

Comments

Jens

I don't know about a possibility to use a relative path.
But you can use STAGING instead of WORKAREA (which is not very comfortable during the developing phase).
Or you can put your inline in a separate branch. So you can use it in different branches and at this point it makes sense that you have to use the complete path.

-- Jens

JonathonG

I vaguely recall that one of the environment variables set for inlines is the workarea path for the current template. So, you could incorporate that into your command line (or, perhaps, write a small script to do it rather than just using 'cat').

I'd supply the syntax, but can't recall how to access an env var in *nix, and I'm at a Windows client these days, so no way to try it.

HTH,

Jonathon
Independent Interwoven Contractor

Migrateduser

the <inline> tag passes 4 environment variables into the command being exec'd: IW_USER, IW_ROLE, IW_WORKAREA, IW_DCT.
You can use the IW_WORKAREA & IW_USER variables for prepending to a common "workarea-relative" path.

______________________
Kerry Kartchner
Interwoven, Inc.

In next story frame.png

jwl

Thanks Kerry.
The examples I've seen for using environment variables are all Perl-based. How do I use these env variables in the inline tag in a DCT?
Thanks.

Capture.JPG

Adam Stoller

If I understand the question correctly - you can't.

You can make use of the environment variables *within* the inline script - but you *cannot* make use of the environment variables to specify the source path for the inline script within the inline tag directive.

I think there might be a feature request on this - at least for providing a means of referencing IWHOME from within the DCT's inline directive so that you don't have to hard-code a path in there, but I don't think such a feature exists ... yet...

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

gzevin

one might use not only staging, but also any other directory ouside of backing store. In some cases I use that technique as well.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

krauseke

This can be handled in the inline perl script. Since you can get the $iwmount and the $vpath you can calculate where you are storing your includes:

|IPL file|
# constants
$DATA_ROOT="templatedata"; # the dir for templates * MUST MATCH /etc/iw.cfg
$FRAG_ROOT="templatefrag"; # the dir for fragments (in a workarea)

use TeamSite::Config;
my $iwmount = TeamSite::Config::iwgetmount();

my $frag_name = $ARGV[0];

# get our dct's vpath from the environment. It will look like:
# /default/main/<branch>/WORKAREA/<workarea>/templatedata/<category>/<type>
my $vpath = $ENV{IW_DCT};

# calc from this the vpath to the templatefrag dir
# e.g.
# .../my_workarea/templatedata/Category/Type
# becomes
# .../my_workarea/templatefrag
my $frag_dir = "$iwmount$vpath";
$frag_dir =~ s/(.*)\/$DATA_ROOT\/.*\/.*/$1\/$FRAG_ROOT/;

{error checking on opening fragment}

# now output our fragment
print "<?xml version=\"1.0\" encoding=\"UTF-8\"?>";
print "<substitution>";
while (<FRAG>) {
print;
}
close (FRAG);
print "</substitution>";

Then in the dct you can call this ipl and pass it the name of the fragment you want to include. Bad thing is that if your fragment has inlines, they won't work... Smiley Sad

|DCT entry|
<inline command="__IW-HOME__/iw-perl/bin/iwperl.exe __IW-HOME__/local/bin/include_fragment.ipl {frag_name.cfg}">

Adam Stoller

I'm not sure how this invalidates my comment - which is that there's no way to invoke the inline script using environment variables - since they aren't processed within the DCT. I.e. there's nothing that I know of that will change __IWHOME__ into the actual path for where TeamSite was installed.

The only way I could see to do this would be through the use of FormAPI to somehow change the contents of the inline command directive - but that requires that the FormAPI code get executed *before* the inlines - and I believe the opposite is true.

Or did I somehow mis-read/mis-interpret your post?

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

krauseke

You are correct - that there is no way to invoke the inline script without explicitly stating the location of the script you want to invoke (i.e. c:/iw-home/...). I may have missed what you wanted to achieve, but the location of your script in the inline doesn't change - unless you reinstall TS in a different location. The ipl that I pasted gets the current location of the DCT that user is working on and then backs up to where you store your fragments. Unfortunately, there isn't a way around having a datacapture.cfg in every branch (even if it just calls the fragment) but you can at least maintain your templates all in one location and 'include' them in every template where needed.

Let me know if I misinterpreted or am just telling you what you already know - but your statement is correct that you can't dynamically determine __IW-HOME__ but I don't believe that is necessary since you are trying to get to a common workarea which can be determined by the inline.

Cheers

Migrateduser

> but the location of your script in the inline doesn't change

Except in some cases when you are sharing code between multiple servers such as dev and prod that have different IWHOME, migrating from M$ to Solaris, etc. IWHOME should certainly be tokenized.