dcr containing a link_id pointing to another dcr

We have dcr, say 1.dcr which contains an id element. The id element references another dcr, say 2.dcr.
If we want to modify 1.dcr using DCT, do we have a mechanism where we can also open up 2.dcr to see what the id element points to?

Find more posts tagged with

Comments

Bowker

you could use a callout to startup a script (must it be perl?) that could display the other DCR in a new window or maybe even launch "view" or "edit" mode within templating.

Adam Stoller

Good idea - I believe you could use a callout (CGI or Java - depending on the TST interface being used) that takes the information from the field and renders it as a CCI URL ("CCI" => "Casual Contributor Interface") .

In the TeamSite Administration Guide 5.5.2 for Windows - see p. 115 - also check out the KB article on the support site: https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=48945

If you're using the browser-based UI for TeamSite Templating - it shouldn't matter what language the CGI script is written in. If you're using the Java UI - I'm pretty sure the callout script *must* be written in Java...

Once the callout page is rendered you should be able to click on the link and get taken to the DCR in question (assuming you used the correct URL syntax). You might even be able to avoid the second click (the first being the callout button) by having the callout script do a redirect to the CCI URL ...

--fish
(Interwoven, Curriculum Development)

conmgmt

Let me make sure I understand what you mean.. ....

What you are saying is... pass the id from 1.dcr to the <java_callout> or <cgi_callout> This call out will look similar to this...

<java-callout location=....
class='abc'
<param name='URL' value='/iw/webdesk/edit?vpath='...
...
</java-callout>

The class abc will get the id from 1.dcr (lets say the id is 2) and append it to the URL inside the code as
/iw/webdesk/edit?vpath=..../2.dcr

So when I click the callout button on the DCT, it will in effect open the 2.dcr in a new window.

Let me know if this assumption is correct. Thanks

Adam Stoller

Your assumption is correct as far as my assumption of how i *think* it should work. I have not personally tried this out.

--fish
(Interwoven, Curriculum Development)

conmgmt

I was able to make a cgi callout and then form a url in .ipl. The way it works is... when the user clicks on the callout button, it opens up a new window, which has a link (the url containing CCI). When the user clicks on the link, the linked dcr opens up in that window.

The above works as I have tried it by forming a hard-coded url. Practically, when the user clicks on the callout button, the perl script should be able to read the vpath and dcr name/value.

Is there a way to read vpath and dcr item name & value in the perl script dynamically ?

Adam Stoller

I'm not 100% sure I understand what you're asking - but I think the answer is "yes" - if you can get the vpath for the URL - you already have access to the vpath. If you use that information to parse the file with something like TeamSite: Smiley Very Happy

CRparser or TeamSite: Smiley Very Happy

CRnode or even XML: Smiley Tongue

arser - you should be able to retrieve information from the referenced DCR.

Is that what you were asking?

--fish
(Interwoven, Curriculum Development)

conmgmt

The question is.... how can I get the current vpath in perl ( I am not passing it as an argument)

Adam Stoller

I guess I'm missing something here - when you filled in the reference field the first time - i.e. to select another DCR to reference within this DCR - the vapath information for the referenced DCR should have been stored in that field - and thus should be accessible from there too.

Perhaps I'm missing a cart-before-the-horse here?

--fish
(Interwoven, Curriculum Development)

conmgmt

sorry about the confusion.... I will explain with an example...

1.dcr has 2 item names namely title and link.
Let's say 1.dcr has the following values.

< title>abc</title>
< link> 2.dcr</link>

When I edit 1.dcr, I have a callout button next to link. The value of link i.e. 2.dcr shows up in the text box.

the callout button looks like this ...

<item name="View Image">
<text>
<callout type="cgi"
label="View Image"
url="/iw-bin/test.ipl/default/main/..../image/data"/>
</text>
</item>

In test.ipl, I get the path as '/default/main/..../image/data' which is passed as argument from the above call.
How do I also pass 2.dcr as the argument to the call, so inside test.ipl I can append the dcr to the path ?

In other words, my final url path should look like this....

"http://server//iw/webdesk/sce?vpath=/default/main/...../image/data/2.dcr"

james1

I believe that your callout CGI will get all fields of the DCT form POST'ed to it (at least, this was the behavior in 4.x, and I don't know that it has changed). Your callout CGI could record all of its CGI form inputs and see if one of them is what you are looking for.

Otherwise, you can send back an HTML page containing JavaScript that finds the value on the DCT form, and then sends it back to your CGI script. For an example of this kind of JavaScript, see IWHOME/httpd/iw-bin/example_datacapture_callout.ipl.

Hope this helps.
-- James

Adam Stoller

My question remains - how did 1.dcr's link tag get filled in with just "2.dcr" rather than the full, or area-relative, vpath to 2.dcr ?

If you filled it in with a browse element - I believe the full path would be there.

If you're hard-coding it - you could just as easily hard-code the area-relative path.

In either case - I believe you should be able to extract the value of that element, with the path, into your callout script - and thus you'd have the information to put together the URL - yes?

--fish
(Interwoven, Curriculum Development)

custom option.JPG

conmgmt

ghoti and james....

Thanks a lot for the inputs so far...

ghoti - we are getting xml feeds into iw. So the full path may not be present ...in other words not filled with browser element. So I am passing the path as an argument to callout.
You are right ... I would append 2.dcr after vpath to get the full url.

I was able to get the callout element name using

my $element_name = $cgi->{'form'}{'iw_callback_var'};

Is there a way to get that element's value; in this case 2.dcr ?

Adam Stoller

See Jame's response about the JavaScript - or look at TeamSite: Smiley Very Happy

CRparser and similar modules (use perldoc on them for documentation or go to http://servername/iw/help/tst/pt/TeamSite__DCRparser.html)

I.e. - you'll have to parse the DCR to find the data you're interested in.

--fish
(Interwoven, Curriculum Development)

james1

> I.e. - you'll have to parse the DCR to find the data you're
> interested in.

There is no guarantee that (a) the DCR (1.dcr) exists (e.g., New DCR), or (b) that the current value in the DCR file is what the value currently is in the DCT form (e.g., Edit DCR, change the value, but don't save the DCR yet).

Again, check to see if the DCT form fields are being POST'ed to the callout CGI; I suspect that they are. Alternatively, use JavaScript to get what you need (i.e., on the first hit to your callout CGI, return an HTML page that contains JavaScript that gets your data and then POST's it back to your callout CGI -- or to another CGI -- and then do whatever you want to do).

-- James

conmgmt

james .. I agree...these are very valid points.. I am sure we might need to have a process around that.... do you feel there is an alternate way to achieve this?

I managed to link to 2.dcr from within 1.dcr. The cgi callout along with cci works.
But I ran into another issue. ....
I created a new dcr, 3.dcr. Inside this dcr, I set the value of the link to 2.dcr, same as in 1.dcr.
I saved the dcr, when I edit 3.dcr and click on callout, a new window opens, but this time throws an error instead of linking to 2.dcr.

Any ideas what might be happening or how to debug this....?

james1

> james .. I agree...these are very valid points.. I am sure we might
> need to have a process around that.... do you feel there is an
> alternate way to achieve this?

If you are refering to alternatives to parsing DCR's, then I presented two of them in my post:

> Again, check to see if the DCT form fields are being POST'ed
> to the callout CGI; I suspect that they are. Alternatively, use
> JavaScript to get what you need (i.e., on the first hit to your
> callout CGI, return an HTML page that contains JavaScript that
> gets your data and then POST's it back to your callout CGI --
> or to another CGI -- and then do whatever you want to do).

If you don't understand what I'm saying in the above, please let me know how I can clarify.

> I managed to link to 2.dcr from within 1.dcr. The cgi callout
> along with cci works.
> But I ran into another issue. ....
> I created a new dcr, 3.dcr. Inside this dcr, I set the value of
> the link to 2.dcr, same as in 1.dcr.
> I saved the dcr, when I edit 3.dcr and click on callout, a new
> window opens, but this time throws an error instead of linking
> to 2.dcr.
>
> Any ideas what might be happening or how to debug this....?

Go ahead and post your callout CGI to this forum, and perhaps (and others)I can take a look at it.

-- James

conmgmt

> Again, check to see if the DCT form fields are being
> POST'ed to the callout CGI; I suspect that they are. >Alternatively, use JavaScript to get what you need (i.e., on > the first hit to your callout CGI, return an HTML page that
> contains JavaScript that gets your data and then POST's
> it back to your callout CGI -- or to another CGI -- and then
> do whatever you want to do).

James....do you have any examples which can help me better understand the above process...

I am attaching the ipl file. I figured out that the error occurs at the following statement
my $rootnode = $parser->parse($xml);

There is no value generated for rootnode, so it breaks on the next step.

james1

Sorry I have been clear. Here are my two alternatives to parsing the DCR to get the value from the field in the DCT form:

#1: It's Already Being Given To You

I suspect that the callout is receiving all of the data in the form in its CGI args already. This was the case in TST4.x. It may no longer be the case. To see if it is the case, you can have your callout CGI print all of its CGI args to a temp file, and see if you see the data you are looking for. I believe you've already found the CGI arg ("iw_callback_var", I believe) that contains the name of the field you are interested in. I suspect that there may be a CGI arg whose name is the *value* of the CGI arg "iw_callback_var"; its value is the DCT field data that you want. You are already doing this:

my $element_name = $cgi->{'form'}{'iw_callback_var'};

So do this:

my $element_name = $cgi->{'form'}{'iw_callback_var'};
my $dcr_path = $cgi->{'form'}{$element_name};

And see what you get. No guarantees that that will work, which is why I recommend you go ahead and dump *all* CGI args to a temp file, to see if it's in there.

#2: Use JavaScript

OK, if you aren't explicitly being given the data in the DCT form, then send back an HTML page that gets it for you.

(All of the following is cut-and-pasted from example_datacapture_callout.ipl.)

my $form_name = $cgi->{'form'}{'iw_form_name'};
my $element_name = $cgi->{'form'}{'iw_callback_var'};
my $user_name = $cgi->{'form'}{'user_name'};
my $item_name = $cgi->{'form'}{'iw_item_name'};
my $item_description = $cgi->{'form'}{'iw_item_description'};
my $dcr_name = $cgi->{'form'}{'iw_object_name'};

print <<"END";
Content-type: text/html

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">

</SCRIPT>
</HEAD>
<BODY onLoad="go()">
<FORM ACTION="/iw-bin/your.callout.cgi" METHOD="POST">

<INPUT TYPE="HIDDEN" NAME="my_data" VALUE="">
</FORM>
</BODY>
END

Now, your CGI should, before anything else, see if it is given an arg named "my_data". If it is not, then your CGI should do the above. If it is, then that means that your CGI has already done the above, and it worked, and the browser has sent you the data you want in the CGI arg "my_data", so you can go ahead and do what you need to do.

This approach unfortutnately involves another round-trip between the browser and the server, so the first alternative is preferable.

-- James

conmgmt

James, thanks for the examples/script.

Did you get a chance to look at the ipl script I posted as an attachment ?

Arrows.png

conmgmt

is there a way to change file permission from within perl script ?

When I create a dcr using templating, the file permissions are set to -rwxrwx---. The perl callout from this dcr fails. When I chaned the permission to -rwxrwxr--, the perl callout worked.
Is there a way to change the file permission in the perl code (i.e. the callout code).

Adam Stoller

I think I may have lost some context here - this thread is getting too long ;-)

What version of TeamSite / TeamSite Templating are you using?

If you're using 5.x I believe that the process that is running the Edit DCR window may be owned by the user "iwui" - if so - you might be able to change the ~/.profile for "iwui" to have a more wide-open umask.

Alternatively - you could perhaps have your Perl script use the chmod() function [see: perldoc -f chmod]

--fish
(Interwoven, Curriculum Development)