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

Auto-generation of output files

System

With just a couple of hours of development (about 200 lines of DCT, FormAPI and Perl CGI) I have a functional prototype that allows the user to select the output directory for a DCR using a DCT select list, which means as long as a DCR only generates output files to one directory I can completely automate generation for the user (get the output file directory from the DCR, base the output file name on the DCR name, get the extension from templating.cfg, etc.).

Firstly let me say that because it's this easy I find it frustrating that Interwoven doesn't provide the functionality in the base product, even if some customers would choose not to use it.

I would be happy to share the code with anyone who would be willing to help me flesh it out - for instance I haven't determined how to prevent the user from being able to generate to specific directories. I also wonder what other issues I should consider, and whether I should even bother with this functionality due to TeamSite 6 (will it finally provide this functionality?). I also seem to remember posts by Interwoven pushing developers towards Java instead of Perl/CGI - is there any reason I should do this with a JSP or servlet instead of a CGI? I don't see where ContentServices or OpenAPI would help because I'm not calling any Interwoven CLTs/APIs in the CGI - just reading from the filesystem.

Any input would be appreciated...

Find more posts tagged with

Comments

gzevin

John,

As far as JSP vs CGIs - I have not seen any JSP callout for Temaplating, so hang on there for the time being.

The ideas looks interesting, and from what I saw so far in TS6, there is not such functionality. Basically, templating is still pretty loose from the core product.

However, I found that the users are more interested in submitting a DCR and generating an output file based on its relative position in the data directory, as very often that position does reflect web site's information architecture.
Just recently there was a discussion on the forum, I have even mailed one gut some scripts that do what I have just described. (and I know many consultants have already written a similar set of scripts).

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

On most projects I have implemented the code for determining the output file location based on the relative path within the data directory. But then to create a new directory users have to navigate templatedata, which I tend to find intolerable. Also save seems silly for many templates, after they have selected the category and type they have to select directories on save (which seems like a repeat operation to some users). Finally move is generally not well supported in any scenario, I am not sure if this approach makes it easier (I was thinking the template would throw a warning if they change the output location on selected in a DCR that had already been saved, or make that field read-only after save unless the user is editor or above, but won't automatically delete and workflow the old output files). I guess my general approach would still be to use the relative DCR path to determine the output file location but this project is migrating existing production from 5.0 to 5.5 and I'm not sure we have the option of relocating all the DCRs or retraining the users to create and select directories.

Anyway the tool for selecting the directory in the DCR is much slicker than the Interwoven default for browsing the filesystem and I think I can give it better control (for instance some users may not be able to browse above certain directories, or the same template used in multiple branches may work differently).

I think I have built callouts, at least callServer code, with JSP on previous projects. I think it is faster. But this project is currently all Perl, which means Perl modules that aren't easily available from Java programs.

Thanks,

-John