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

Getting rid of multiple PTs

System

Hi All,

Here is what I am trying to do:

I have my press release data capture template.
and I have 3 presentation templates.

1) Press release page.
2) Printer friendly version of press release.
3) Table of contents.

I did not want my users to select these PTs 3 times and generate the files seperately.
So I have called CLTs iwgen and iwregen from PT 1 to generate the pages using PTs 2 and 3.
It worked fine as long as I had the entries of PTs 2 and 3 in my templating.cfg.
Having done this - users now need not select PTs 2 and 3 from the selection pop up -
selecting PT 1 would generate or regenerate printer friendly page and table of contents page.

The only problem which still remains is - user still have to select PT 1 from the PT selections popup.
If I remove PTs 2 and 3 from the templating.cfg file, there is no selection popup shown to user - but
at the same time iwgen and iwregen stops working.
So it seems iwgen and iwregen still needs entries for these templates in templating.cfg.

Is there anyway we can remove PTs 2 and 3 from config file and still have iwgen and iwregen work?

Thanks,
Ravindra

Find more posts tagged with

Comments

mogoo

We're currently dealing with a similar issue. You could automatically generate #2&3 with <iw_ostream> in #1.

Alternatively, you could generate #2&3 with iwpt_compile.ipl from the command line. This is something that could be written in to a workflow or the #1 tpl.

If you use <iw_ostream>, all the logic would be in the #1 tpl. If you generate via iwpt_compile, you'd have 3 tpls, but you don't have to have the tpls in templating.cfg, hence they would not show up as an option.

Hope that helps,
maureen

Adam Stoller

The two methods already suggest are what i too would have suggested as ways around this.

However, keep in mind, if you want / need extended attributes on the generated files (2 & 3) you will probably have to set them yourself.

iwgen / iwregen use (are constrained by) templating.cfg and *will* set EA's on the generated file(s)

iwpt_compile.ipl, and I believe iw_ostream, do not use (and are not constrained by) templating.cfg, but also do not set EA's on the generated file(s).

--fish
(Interwoven Information Guy)

Migrateduser

Maureen and Fish,

Thanks a lot for your replies...

I have already implemented my solution using iwgen and iwregen...

So, I just wanted to have a feeling how much of an effort it is to change it to use either iw_ostream or iwpt_compile...

Does iw_ostream and iwpt_compile do both jobs (generation and regeneration)?
What I am doing is - I first check if the file already exists - if it does I regenerate it, otherwise just generate...
Can something like this be achieved with iw_ostream or iwpt_compile?
Out of these two - which one do you recommend?

Maureen - if you have done something similar - can you please post the part of your code here?
(trying to find a shortcut )

Thanks,
Ravindra

Adam Stoller

iwgen makes use of the templating.cfg *and* sets extended attributes on the generated file.

iwregen makes use of the extended attribues on the generated file to regenerate the file - and sets/preserves extended attribues on the generated file.

Both iwgen and iwregen are essentially wrappers around iwpt_compile.ipl.

If you use iwpt_compile.ipl directly - you will not get the extended attributes placed on the generated file (unless you write code to do so).

You would also probably have to write your own script for doing 'regeneration' - which would look at the extended attributes and run iwpt_compile.ipl again. I'm not 100% positive about this - but I think you would need to do this because I think that iwregen may be constrained by templating.cfg in the samw way that iwgen is.

iw_ostream is a different issue - as that comes into effect *within* the PT - and you have to figure out if you're using iwgen/iwregen or iwpt_compile.ipl first. At this point I don't remember what it was you were trying to achieve any more (part of the problem with web-based forums ;-) so I cannot effectively comment as to what kinds of hurdles you'd be looking to jump if you used iw_ostream (it's a very powerful function, but that sometimes complicates things)

--fish
(Interwoven Information Guy)

mogoo

Ravindra-

fish makes some excellent points about the EA's, it's something we thought of as we were deciding on which route to take. For our situation, we concluded that we can sacrifice EAs, as we'll be running a nightly cron job that builds the index page based on the html pages in the press directory. i.e., no human interaction on the index page, so it's not necessary to keep track of how it was built.

For your situation, I think <iw_ostream> would be a great solution to build the printer-friendly pages with. It would live in the tpl for your press section, and a printer-friendly version would be ostream-ed every time a new page is generated.

The index page, on the other hand, is built based off of multiple DCRs, right? What we've done is write a script (within our index.tpl) that crawls through the /press/ html directory and checks if pages are current pr's. We then grab the appropriate info out of the associated DCRs to build teh index page. We decided to invoke it via iwpt_compile on a nightly basis via a cron job because you don't need a DCR to generate an html page, you can just call on the tpl. I'm not sure what this line of yours means...
> What I am doing is - I first check if the file already exists - if it does I regenerate it, otherwise just generate...
...what files are you checking to see if they already exist? With <iw_ostream> and iwpt_compile, we're just overwriting the existing file every time.

Hope that helps!
maureen

Migrateduser

Thanks a lot Maureen and Fish for your valuable inputs.

I have not yet finalised as to which route to take - iwgen/regen or iw_ostream.
I will analyse this based on your feedbacks.

Maureen - when I said I check if the file exists - I was referring to the printer friendly page. If I am creating a new DCR and generating the page for the first time, I need to create a new printer friendly page. If I am doing regeneration of the press release - printer friendly page already exists and I need to regenerate it.

Thanks,
Ravindra

ela

Hi Ravindra (or anybody else with similar solutions),
I'm curious to know which solution you chose and if you could provide some details/code, as I would like to do something similar. That would be a great help!
Thanks!
Eldbjoerg

nico

Yes it would be great to see a final tpl with the ostream solution to outputting the pr and pr printable page.

Thanks,
Nico