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

Submit button on CGI form

cemman01

It looks like something has changed with the way the instantiator now handles buttons (submit, cancel) on a CGI form while invoking a workflow.

In the TS5.5.2 version, the state of the submit button could be read by the tag 'iw_submit_action'.
<input type=hidden name='iw_submit_action' value='true'>


Apparently this is not set in TS6.0 but is handled by a class
<td nowrap valign="middle" align="middle" background="/iw-cc/base/images/dialog_btn_mid.gif">
<a href="javascript&colon;document.forms.iwwft_instantiator.submit()" class="iw-base-actionlist-link">

Submit

How do we now read in this value? Do you use Javascript?

I would like to know more on how the instantiator works. In our submit workflow, we increment a flag value so that the instantiator reads the cgi form\window twice. This too seems to have slightly changed in 6.0.

Find more posts tagged with

Comments

Migrateduser

The "iw_submit_action" parameter does not appear to be one of the publicly documented and supported request parameters shown in the Workflow Developer's Guide, and indeed it is not present in TS6.0. When a job is not initiated from a button press, it is meaningless to ask for the state of a button. However, you can define your own hidden counter parameter in your WFT to keep track o fthe number of times that template has been evaluated.

The "class" attribute servers an entirely different purpose. This specifies the format for rendering the HTML.

Brinko Kobrin
Interwoven Staff Engineer

cemman01

We have a parameter that does keep track of the number of times the wft has been evaluated. We use this to forcibly bring up the cgi form that we create for the first time, otherwise it gets skipped and goes directly to the submit cgi window. This was not documented either.

However our main concern is with the submit button. If it is selected, only then is the submit cgi window called. In order to do this, iw_submit_action patameter proved useful and we need to track the state of the button.

Since this is no longer available in 6.0, what is IW's advice on handling the submit button\run job on a custom CGI form when it is selcted?

Migrateduser

I don't fully understand the condition that you are trying to create (or avoid).

You refer to "the submit cgi window" and a "custom CGI form". Are these the same thing? Are you talking about customizations within a WFT, an immediate CGI task, or something else?

Perhaps relevant code snippets would help to clarify what you did with the earlier release.

Brinko Kobrin
Interwoven Staff Engineer

cemman01

All we want to find out is if the submit\Run Job button was clicked in form created by the workflow instantiator.

In our current 5.5.2 release, we modified the default submit workflow. The way the submit workflow behaves OOB is that when a user selects the Submit button in the TS UI, the submit workflow gets kicked off and the user is presented with a submit form to enter submit and individual file comments, overwrite and keep locks options..etc.[see screenshot2]

We modified the worfklow to invoke a form (created in the workflow using CGI info tags) before the submit window appears.[see screenshot 1]. Upon selecting the Submit button, the submti window (as in screenshot 2) gets called. If Cancel is chosen, the workflow ends.

In 5.5.2, the iw_submit_action field helped us accomplish this. I was under the impression that this field is not used in 6.0 but a co-worked investigated that under a special submit condition, it does get set. This is shown in the iwwft_instantiator.ipl file. Also what does the description for iw_hide_buttons imply? From what I understand, it looks like it may apply to us.

Edited by cemman01 on 01/06/04 11:41 AM (server time).

Adam Stoller

Screenshot 1 can probably remain as is.
Screenshot 2 should be able to be handled by an immediate / start task / cgitask script - which could process the files to determine if it needs to show the form at all (if not, just send a callback and exit, otherwise ...). The submit button on this form would do a callback to the next task in the workflow process. The cancel button could use a different callback value that immediately transitioned to the endtask.

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

cemman01

The processing is handled in screenshot1 already and the output of the processing is shown. Even if it is handled in a cgi task (which we have done for other things that we check for)the problem still remains on determing if the submit button was clicked upon.

Would you loop though the elements of the form and for the submit button, use the onlick event handler to determine if the next form should be shown?

Adam Stoller

Hmm - perhaps I got confused by the ordering of he screen shots - I'm used to '1' preceeding '2' not the other way around.

I'm surprised something like this ever worked.
You should be able to tell that the Submit button has been clicked the way you would in any CGI program - and you can add javascript code to the form so that when the button is clicked it disables both the Submit and Cancel buttons in the current form, so that they cannot be clicked on multiple times (the code for this was, I believe, posted somewhere on DevNet and should also be available through Support).

However, all that aside, I don't see how you can do what you're asking unless *both* screenshots come from a cgitask script *within* the workflow - rather than trying to do it all outside the workflow during the instantiation process.

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