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

Event handling at generate time?

enthusiast

We have a DCT that does the following:
1. Generates a .jsp page
2. Once generated, user browses and adds the generated .jsp to one of the empty field in the DCT.
3. Deploys to a table in database

My question: Is there a way to capture the name of the generated .jsp file at Generate time and populate that browse field automatically before deploying it to the database?

thanks.

Find more posts tagged with

Comments

Adam Stoller

How are you generating the JSP file?
Via CallServer()? or a callout?
In either case - I would imagine you should be able to capture the name since it needs to be supplied somewhere (doesn't it?) - and if so, you should be able to feed that information back into the DCT form via FormAPI calls.

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

enthusiast

I am generating the .jsp using .tpl file. Can I still do that?

Adam Stoller

I assumed you were using a PT - but you indicated that this is happening through the DCT form, which I took to be a distinct DCT form from the JSP DCT.

Perhaps you need to provide a bit more detailed explanation of what you *are* doing and what you *want* to do to make it clearer.

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

enthusiast

Ok, we have a regular DCT form along with a presentation template. These 2 combine to generate a .jsp file. As soon as the .jsp file is generated, I need some kind of process to capture the path to that generated file and populate it to one of the field is the same DCT. Once that part is done, the user will click the finish button and kick of a workflow which will deploy the content of that dcr along with the path to the generated .jsp information to the database.

Adam Stoller

Does the path to the generated file need to be embedded *within* the DCR - or can it be attached as an EA?
The latter could very easily be done via the PT.
The former could be done within the PT too - but it takes a bit more coding since you have to parse *and* modify the DCR while processing it.

RTFM for iwpt_ functions dealing with 'ofile'

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

enthusiast

The desired functionality is to have it appear in the DCT as a field value. I think I can parse the dcr to insert that information but I am not sure how to refresh the dcr afterwards so that the empty field won't overwrite the dcr value at the time of deployment. Also, I am not clear on how to retreive the path to the generated .jsp file in the PT to write it to the current dcr field?

enthusiast

Is it possible to use the following in PT to update the field instead of writing it to DCR directly?
<iw_perl>
<![CDATA[
print <<EOF;
<script language="javascript">
api = parent.getScriptFrame();
api.IWDatacapture.getItem("/field").setValue("/test");
</script>
EOF

]]>
</iw_perl>

reddyl

You should not use Form API in the presentation template, FormAPI is used in the DCT. Presentation Teplates are run on the server and JavaScript runs on the client machine. So you can parse the DCR in the presentation template for the specific field and the either update the DCR field or modify the value.

~ reddy

enthusiast

But how would you know the name of the generated jsp in PT file before you actually browse the dcr and update it?

Adam Stoller

It sounds like we have a chicken-and-egg situation here.

Should the name of the generated JSP file be determined *prior* to it being generated - or does a [hidden? readonly?] field within the DCR simply need to be filled in *when* the JSP file is generated, but before the DCR is deployed?

If the former - then there may not be a file to select with a browser element, so it will be the burden of the user to provide the correct path / filename for the to-be-generated JSP and the generation process (custom callout on the DCT form?) would then use that information when formulating the command line to perform the generation.

If the latter - the PT can retrieve the name of the generated file via iwpt_get_ofile_name() call within an <iw_perl>...</iw_perl> section of the PT - and then use an XML parsing module to replace the value (empty or otherwise) within the DCR with the value retrieved from the aforementioned method. The parsing of the DCR should be fairly easy using either TeamSite: Smiley Very Happy

CRnode or TeamSite::XMLnode modules if the DCR is of type "iwov". If the DCR is of type "xml" you can use either of those modules or a number of other "standard" XML parsing modules that provide for functions to modify the content.

In this latter case - I suggest writing a standalone script to do what you want to verify the code and then incorporate the code (once working) into the PT.

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