Perl STDOUT/STDERR: ostream vs. iwpt_compile.ipl

I wonder if there should be a Perl forum.

If I have a presentation template that invokes another presentation template to generate another file, I would like to know whether the second presentation template generated anything to STDOUT/STDERR which I would normally detect as error or warning messages. I can do this with iwpt_compile.ipl using backticks. Is this also possible using the ostream functions?

In fact I would like to know whether the "parent" presentation template is generating anything to STDOUT/STDERR. I imagine this can be done with "SELECT" but I can't figure it out from the perldocs. Any pointers?

If I do invoke iwpt_compile directly, for performance I would prefer to use "do" instead if backticks. Is there a way do I trap STDOUT/STDERR with "do"?

TIA,

-John

Find more posts tagged with

Comments

Adam Stoller

Not sure about the specific questions you're asking - but if you can - avoid having a perl script call another perl script. Instead, write the second perl script as a module and have the first perl script call methods or subroutines within that module.

Anytime you use system(), back-ticks, qx(), etc - you are causing another shell process to be spawned and its going to cost you in terms of performance.

You might want to take a look at this document I put together a couple of years ago: Making Your Perl Scripts Efficient ...

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

Migrateduser

But the Perl script I am calling comes with shrink-wrapped software (teamsite templating), is named iwpt_compile.ipl and is being called from a Perl module referenced from a DCR. It would be great if there were a way to call the work iwpt_compile.ipl does with a module instead of as a standalone script, but is there a functional/documented way of doing this? Personally I would never write Perl scripts that run as back-end processes to write to STDOUT/STDERR (such as iwpt_compile.ipl does when it encounters various types of syntax errors) as that output is not trapped (or at least I would write it to STDERR and put it in a variable the program has access to), but I didn't write this one.

Adam Stoller

Touche regarding iwpt_compile.ipl -- it would be nice if there were a modular interface for calling it in addition to the CLT approach.

However, if you do a iw_load_dcr() and/or an iw_include, and use iw_ostream - I'm not sure you need to invoke a sub-process for iwpt_compile. At least that's the way I'd try to approach it.

Also, having re-read your initial post - I don't think there would be a problem with the parent iwpt_compile process capturing STDERR output from the child iwpt_compile process - but I've not tried it.

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

Migrateduser

I'm not sure the ostream functionality will help me, but may be there is a better solution than what I'm doing.

The reason for multiple iwpt_compiles.ipl is that the same presentation template is used to generate web, secured, printer-friendly and potentially "brochure" transformations of the DCR (I have tried to sell them on XSL but it's considered too much of a risk). So the presentation template is called for multiple output files. The difference between the generated files have to do with links (fully qualified for https, absolute for all others), virtual includes (printer-friendly and brochure don't include header, footer, left nav, etc.) and brochure does not include head/meta html tags (multiple brochure files are aggregated by another template that adds these tags). The actual call to iwpt_compile.ipl is in a module that's called from the presentation template itself. Of course this can result in infinite loops but it seems to be working as it is.

Is there any way I could use the ostream functions for this?

Thanks,

-John

Johnny

I dont know if it meets your setting, but i can tell you what i do that sounds similar.

Whenever I need to generate multiple formats or different view (index etc), I use one main template that does nothing else except call other templates via iw_ostream and iw_include.

It also allows me to only need to register one template so that users dont need to select any templates. Depending on what selections were made, or whether preview was selected, the appropriate template(s) are called via iw_include with an iw_ostream housing the block.

I guess every situation is different, but i have done this at numerous installations and they alway seem to solve the problem at hand.

John Cuiuli

Johnny

XSL can be process within a presentation template aswell.... its got the works!

John Cuiuli

Migrateduser

Thanks for the suggestion.

There are numerous templates (dozens of DCTs and hundreds of PTs) here and one of the goals of the site redesign is to minimize this. Having one tempate that calls itself means a lot less templates than this ostream/include approach, so I'm not sure the performance issue outweighs the code maintenance issue. Plus, if it's all done with a module, each template just calls a method on an object instead of having all of the logic for generating multiple files in the parent templates. If you could post an example of a parent PT that generates multiple output files, and the code is less than say ( number of output files plus 2 ) lines, then it would probably be an option. Or if there's any way for moving the logic to determine output files and what templates to call to a module.

I'm not saying this way is better, I just think it meets the goals of this specific project at the cost of performance.

Migrateduser

Yeah but trying to convince management, technical leads and other developers to invest in a "new" technology is a challenge. Anyway I try to stay as far away from templating as I can.

Johnny

I can send some examples tomorrow when im back at the office.

You are right what you say, and every situation is going to be different. So long as you have all the facts then you will be the one that makes the right decision.

I know for my uses I have always tried to stay inside the TST realm as it does make maintainance easier for the teams. Like i said before, being inside templating allows me to find out what files have been generated, it also allows previewing of all of those files and it gives me a consistant abstract method/mindset for generating files. You could have a TPL and a DCT include container that could act like your module. All templates call them and depending on entries in your dcr, the common TPL performs certain actions.

In the end, you know the exact situation/requirements and the direction your client wants to go. There is always a zillion ways to do things, sometimes its a problem in its self !

John Cuiuli

Johnny

This is a simple template that checks to see if the user clicked preview.

If so the preview template is called, if not the real templates are called. The main two templates that are called for generating, create alot of small includes so they take care of their own multiple iw_ostreams.

It would normally make sense for the parent template to define the ostream before the template is called, so that the sub_templates are still fairly abstract. It all depends on the situation though.

I dont know how relevant this template is to your needs, but as said before, you could have a few fields that are used to determine what needs to be done for template calls. That logic could be factored off into sub templates themselves.

John Cuiuli