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

parse_data() Call Failing in Templating

RyanS

I am attempting to convert some perl in a Template from 5.0 to 5.5 and am having some trouble. I've looked at the "show_env.ipl" example and copied it exactly. The issue that arrises, is that when the template is previewed (I've now chomped down the template to virtually nothing to figure this out) it comes to the line cgi->parse_data(); at which time it hangs. Enough of these will hose the server.

When looking in the processes on the server I see two processes.
1. IW_CGI~1.CGI
2. iwtemplpreview.c (the rest is cut off)

If left to it's own devices, these will not go away. Upon killing "IW_CGI~1.CGI", it will SOMETIMES respond and the template will load (but not with the values from perl).

When executing the "show_env.ipl" file again, it loads properly (so the call works, but it seems to hang in Templating).

I had this working ONCE. It made the call properly and never again. I've logged out and logged back in again with no resolution to the problem. I stripped out EVERYTHING from the template. Left just the <iw_pt /> and <iwperl> tags. Inside of the perl I copied straight from the "show_env.ipl". My template currently looks like this:

<iw_pt />
<iw_perl>
#!c:\iw-home/iw-perl/bin/iwperl

use TeamSite::CGI_lite;

$|=1;

$cgi = TeamSite::CGI_lite->new();
$cgi->parse_data();

</iw_perl>

and believe it or not.. it still hangs.. I'm baffled.. this code works in the show_env.ipl file, but not when in the template? This can't be so...

any suggestions?

Find more posts tagged with

Comments

Adam Stoller

I don't know if show_env.cgi was ever intended/tested in use within a presentation template - the things that come to mind are:
(1) you don't need the #! line
(2) it is possible, and likely, that the form variables have already been parsed and that $cgi->parse() is sitting there looking for information that no longer exists.

Hopefully someone with more inside/insight to the presentation template processing will be able to provide a bit more details here.

However, the question that comes to my mind is: What are you trying to accomplish? What piece(s) of information are you trying to access?

It may be that there is already an established way to do what you are trying to do.

--fish
(Interwoven Senior Technical Consultant)

RyanS

Yes.. you are correct.. the # line isn't required.. but to avoid the "You didn't copy EXACTLY" schpeal, I threw it in..

I'm attempting to get the "area_path" parameter:

my $path = $cgi->{form}{"area_path"};

The template uses this path, along with a path entered by the user, and loops through a destination directory pulling in word docs, excel files, etc, and making them into a page with links. We have hundreds of docs, and this template simplifies having to code each link individually. The previous version worked perfectly.. now having to change to this, I start getting this error...

Adam Stoller

Try using something like this:
<iw_perl>
my $path = iwpt_get_dcr_name('dirname');
$path =~ tr|\\|/|;
$path =~ s|^.*/WORKAREA/[^/]+)/.*$|$1|;
</iw_perl>

Hope that helps.

--fish
(Interwoven Senior Technical Consultant)

RyanS

Well.. getting the value from the DCR isn't the problem.. they've been putting in a path relative from their site.. then I was generating the TS path (y:\default\main\blah\blah\blah) then joining the two together... since that TS path changes depending on what workarea they are in, I need to pull it from the TS params... then my perl code uses that entire path (TS path + user entered path) and looks for documents at that destination folder, pulling them in to compile it as a bunch of links on a single page...

So it's not the path entered that's the problem.. it's the area_path param I'm having trouble getting...

james1

Well, PT's aren't CGI's, so you shouldn't, inside of a PT, assume that you are in a CGI environment. parse_data() is probably trying to read from STDIN, where CGI's can get their inputs, which is making it hang, since a PT will have no inputs on STDIN. So your PT is just sitting there, trying to slurp CGI inputs from iwperl's STDIN, which has nothing coming in.

If you are trying to get the current area vpath, a lot of people derive it from the DCR path or the ostream path. See the docs for <iw_perl> for more.

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering

RyanS

That makes no sense. If I'm not able to interface with a CGI environment, why do we even have <iwperl> tags? Isn't that supposed to construct the "CGI environment" so my Perl would execute?

RyanS

In reply to:

See the docs for <iw_perl> for more.

As a note...

The Dev Guide for TS 5.5 is extremely lacking in this area.. as well as the online TST guide for <iwperl>... There's no mention of extracting the VPath in either sets of documentation.. I'll peruse DevNet...

james1

> That makes no sense. If I'm not able to interface with a CGI
> environment, why do we even have <iwperl> tags? Isn't that
> supposed to construct the "CGI environment" so my Perl would
> execute?

No. The purpose of <iw_perl> is to allow you to write arbitrary code to perform complex computations that you cannot perform with the existing set of PT tags.

One example of its use is calling the "iwextattr" CLT to set or get EA's. There are no PT tags today that can do this for you. But I know that there are people who want to set or get EA's, and they do it by dropping into an <iw_perl> section and writing Perl code to do it for them.

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering