getting current DCR name from a DCT inline command

i have a datacapture.cfg with a call to an inline perl script. i understand that the DCT is parsed and run whenever someone opens a DCR belonging to that DCT, so it seems possible that whatever Interwoven component is processing the inline DCT commands also knows the name of the DCR being edited. my question is, how to can i access the DCR name? my perl script needs to key something off the specific path of the DCR, but i have no idea how to pass the current DCR name to the inline perl call.

currently, the only environment vars my callout script is seeing are these 4; nothing for DCR:

IW_DCT: //server/default/main/site/WORKAREA/working/templatedata/category/template/datacapture.cfg
IW_ROLE: admin
IW_USER: jm3
IW_WORKAREA: //server/default/main/site/WORKAREA/working

how can i get the path to the current DCR? do i have to use FormAPI here? i'm hazy on this.

Find more posts tagged with

Comments

Adam Stoller

I think you'd have to use FormAPI or a cgi-callout.
You can always file a feature request for inlines to be passed another environment variable if it's a DCR being edited as opposed to being created - but unless you can wait to do your implementation (and influence IWOV to implement your request) - I think you'll have to opt for one of the other mechanisms

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

jm3

so conceptually, i could have some simple DCT with embedded formapi or callout code that 1. retrieves and passes the current DCR name to my external perl script, 2. which then runs and returns the real DCT info that my form needs (in substitution file format or something similar)? my first thought was that once interwoven has parsed the datacapture.cfg, it would be too late to re-write the form fields, but i guess that's what formapi does. FormAPI's conflation of server-side files (DCTs) which get parsed by server-side code (IW) to output client-side code (JS) which calls server-code (formapi) to return client-side code (JS) confuses me, a little.

jm3

actually, to clarify: the FormAPI or callout needs to add items to the datacapture form (basaed on knowledge of the DCR filename); this is what the perl code in the subsitution script currently does. i'm fine with rewriting it in FormAPI, but i don't see any methods within the 6.0 FormAPI DCTItems reference that create IWItems on the fly. this is possible?

Michael

Hi John

Generally the approach with formAPI seems to be to have a single DCT/set of fields and to hide and show these fields as appropriate (rather than actually adding or removing these fields).

If this doesn't meet your requirement it might be worth explaining why you want to add fields based on the DCR filename -- there might be an easier way.

Cheers
Michael

Adam Stoller

As Michael pointed out (but I'll rephrase[*]):

Inline scripts are processed at the time of initial construction of the to-be-rendered DCT form, as such they can be used to add fields or even entire chunks of DCT code, but they are operating at the DCT-level and are not provided any information about about the DCR which maybe in the process of getting edited.
FormAPI is generally executed directly after the construction phase during the rendering phase of the DCT form - with the contents of the DCR (if any) being plugged into the respective fields in the form. As such, FormAPI can be used to hide/expose fields and alter values of fields - but it is *not* intended to "physically" add/remove fields from the DCT form structure.
[cgi-]callouts are manually run by users after the DCT form has been fully constructed, and are generally associated with a given field in the form (e.g., perform a db callout, present the results to the user within a separate window, and then take whatever choice they select and fill it into the main DCT form as needed.

From what I gather of your needs:

inline scripts won't work because they happen too early.
FormAPI scripts won't work because they don't add/remove fields -- unless you can include all such fields in the DCT structure to begin with and use logic based upon the DCR name (or lack thereof) to hide/expose certain sets of them.
cgi-callouts scripts **might** work if you consider them as potential windows into sub-forms - i.e. if the cgi-callout cannot find the name of the DCR it could present a message indicating that the DCR needs to be saved first before using the callout. If the cgi-callut can find the name of the DCR, it can render a case-specific sub-form that when saved/submitted, could either write data as EAs on the DCR or write a consolidated string (semicolon-separated, comma-separated, etc.) into a hidden DCT field.

[* The descriptions provided are my own layman's way of indicating what takes place in what order - there may be technical inaccuracies]

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