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

Help with value of <item> in container

summergs

Can someone please tell me how to reference an item in a 'replicated' container on TS6.1?
I have a perl script that I am trying to retrieve it via:
my $testValue = $cgi->{'form'}{'Documents/Type/0/TestID'}; (where 0 = the 'replicant' number)

Thanks!

Find more posts tagged with

Comments

Dwayne

I assume that this is from a callout, correct? Otherwise, I don't know why you'd be using Perl code.

As far as I know, it isn't a supported operation to read the data values via the $cgi object in a callout handler. However, that doesn't mean that it can't be done - just not supported. I would suggest you change your callout definition to point to show_env.cgi instead of your "real" CGI handler. When you invoke the callout, you'll then get a dump of all of the parameters that are being passed to the handler, and their values. That should help you figure out the correct names for whatever it is you're trying to access.

Once you've got that, you can put back the real handler.

--

Current project: TS 5.5.2/6.1 W2K

summergs

Yes. Thank you for reminding me about that. The return on the 'replicant ID' is 15 for the first item and 27 on the second item.. what the heck??
ie. Documents/Test/15/CatID

Is there any way to know what id's would represent which 'replicant'?

Dwayne

That's where we get into that whole 'unsupported' thing. Interwoven never made any promises (API) about how data from the form would be represented to a CGI handler, or even that it WOULD be represented. As I see it, you've got three choices:

Handle it via FormAPI. Your CGI handler could end up being some JavaScript code which would extract the data you care about and populate it into some hidden fields on a new form, and have THAT form post to your "real" handler
File a feature request, and wait. (Not mutually exclusive of the other two, of course)

Current project: TS 5.5.2/6.1 W2K

summergs

Oh poo. What concerns me even more is my datadeployment configuration files as they use the repID's. Surely there must be a way to reference a specific 'replicant'?

Dwayne

DataDeploy is different. That API IS defined, to use the syntax that you've been using. It's only the CGI callout interface that's going to give you grief.

DataDeploy is reading the DCR directly to get the values. The CGI code is getting it's data from the in-memory form in the user's browser. The fact that the data will end up looking like a DCR does not guarantee that it's stored that way in memory.

--

Current project: TS 5.5.2/6.1 W2K

Edited by Dwayne on 09/21/04 11:42 AM (server time).

summergs

Ahhhh...Thanks for the info!

summergs

You know...the thought has occured to me to strip the 'replicant id' from the iw_callback_var
That way it should always be valid

Dwayne

That's probably true, provided:

A: you only want to access items in the same replicant as the one associated with this instance of the callout

and

B: you trust Interwoven not to change the ground rules on you. I'd go way overboard on documenting that this is using unsupported functionality.

--

Current project: TS 5.5.2/6.1 W2K

summergs

Good Point. Thanks!!