Presentation Template to generate TEXT file output

Hi,

I have a Presentation Template which currently genarates a HTML page as output. I want to have another PT for the same DCT which will generate the output as a TEXT file instead of HTML file, with the same contents available in the DCR. How to achieve this? What changes do I need to make in the PT

Please advise.

Thanks.

Leo

Find more posts tagged with

Comments

stefanmaier

Hi Leo,
in the file <iw-home>/local/config/templating.cfg you can define the connection
between presentation templates and filetypes.
There you can set the extension parameter to txt.

<data-type name="out1" dcr-type="iwov">
<presentation>
<template name="mytemplate.tpl" extension="txt">
...
</template>
</presentation>
</data-type>

I hope, this helps..

Stefan

lhdavis

We actually have one tpl that generates a html and txt version at the same time. It is listed in templating.cfg with an html extension but in the tpl we have code that writes out the html to a txt file.

I'm sure the spacing will get screwed up but here is a snipper

<iw_perl>
$filename = substr(iwpt_get_ofile_name(),index(iwpt_get_dcr_name(),'templatedata')-1);
$filename =~ s/\\/\//g;
$txtfilename = substr($filename,1,length($filename)-6)."_txt.html";
</iw_perl>
<iw_ostream file='$txtfilename'>

<![CDATA[
<html><head>
<title><iw_value name='dcr.Title'/></title>
<meta name="subject" content="<iw_value name='dcr.Subject'/>">
<meta name="keywords" content="<iw_value name='dcr.Keywords'/>">
<link href="/test/css/internet.css" rel="StyleSheet" type="text/css">
<script>
var pageid = "/<iw_value name='$txtfilename'/>";
</script>
</head>
<body>
<div style="font-size:xx-small">
<a href="#PageContentArea"><img src="/test/images/clr_pxl.gif" width="1" height="0" border="0" hspace="0" vspace="0" alt="Skip navigation"></a>
</div>
<p align="center"> <script language="JavaScript" src="/test/components/navigation.js"></script>
</p>
<a name="PageContentArea"> <iw_value name='dcr.content'/></FONT></P></SPAN> </a>
<p> 
]]>
<iw_iterate list='dcr.Links' var='links'>
<iw_if expr=' {iw_value name="links.Link Text"/} ne "" '>
<iw_then>
<![CDATA[
<li><a href="<iw_value name='links.Link URL'/>"><iw_value name='links.Link Text'/></a>                </li>
]]>
</iw_then>
</iw_if>
</iw_iterate>
<![CDATA[
</p>

<p class="lastmod"> Page Last Reviewed or Updated:
]]>

<iw_perl>
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
@mons = ("January","February","March","April","May","June",
"July","August","September","October","November","December");
$now_string = @mons[$mon]." $mday, ".(1900+$year);
iwpt_output($now_string);
</iw_perl>
<![CDATA[
</p>
</body>
</html>
]]>


</iw_ostream>

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

gzevin

We actually have one tpl that generates a html and txt version at the same time. It is listed in templating.cfg with an html extension but in the tpl we have code that writes out the html to a txt file.

yes, using iw_ostream is an option - especially in this case, and also when a printer-friendly file is generated at the same time.

however, one should always remember to attach these file to the workflow as they do not get attached automatically.

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

lhdavis

Excellent point, Greg. As we are on 6.x, our users manually generate the output (html and txt files) and they both show up in their Work In Progress component. So our user manually submit both versions from the WIP using our workflows.

If you were generating the output files in the workflow though, you would need to attach both the html and txt files.

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Adam Stoller

Also note - if you use iw_ostream (or just Perl open()/print/close()) the *additional* files that are created will *not* have TeamSite Templating extended attributes associated with them by default. You need to take care of that yourself (either within the PT or via a follow-up process that runs after the files are generated -- discussions about how to do these [either way] have been posted in the past so you can probably find the details if you search the forums a bit)

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

ohkal

Is there a quick way to just copy the actual DCR xml contents, tags and everything, into an xml output file generated with a PT? This way if the DCT changes the PT won't have to since it will just copy whatever is the DCR.

Adam Stoller

Not sure what you're asking for here. The PT generally functions by parsing the DCR's XML and allowing you to determine how that data should be formatted for output. If you are using the "iwov" style of DCR you probably do *not* want to use that XML for your XML output and will want to do some translation via the PT (or through some XSLT script).

If you're using the "xml" style of DCR - then you could either reference the file directly from where it lives in the templatedata/.../data/ directory or you could have the PT perform a copy (e.g. using the File::Copy perl module, or just open/read/write/close routines)

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

ohkal

Why do you suggest *not* to use the iwov style of DCR for the xml output?

Basically what I am trying to do is generate an xml output file that is exactly the same content as the DCR itself, tags and everything. Our portal gadget developers will be extracting values directly from this xml output for their presentation purposes. They have seen the iwov style DCR and are willing to work with that. But if there is some incongruity in this type of xml output, please let me know.

I did some trials where I had some perl in the PT perform a copy of the DCR to a specified folder, essentially generating nothing. The copy works fine but if users want to edit the output, i.e. the copied file, it is unfortunately not associated with the DCR, as normal output would be, and therefore does not open in the DCT. I would like to avoid making the users go into the data folder to edit the actual DCR.

I thought maybe if I added the extended attributes, TeamSite/Templating/PrimaryDCR & TeamSite/Templating/PrimaryDocumentType, to the file as it was copied, that it would open up in the DCT upon edit, but it does not.

The reason I didn't just create a normal PT that would translate the DCR to an XML output was because the DCR itself was already a sufficient output and it seemed like a waste of time to translate something into the same thing that it already is. Plus if the DCT ever changed, then the PT would have to change accordingly. So it would be nice if there was a way to just dump the entire contents of the DCR, tags and everything, into an actual generated XML Output file.

Any ideas?

SMB

You could also use two presentation templates and generate both of them at the same time. The following code inside <head></head> tags in one PT will generate the second file. This solution will also create the extended attributes.

<iw_perl><![CDATA[

$path = iwpt_get_dcr_name();
$dcr_path = "\"$path\"";
$dcr_name = iwpt_get_dcr_name('basename');

$pt = "\"\\default\\main\\my_branch_name\\WORKAREA\\work_area_name\\templatedata\\my_category\\presentation\\txt.tpl\"";

$parm = iwpt_get_flag_param('-oprefix');
if ($parm eq '')
{
$output = "\"\\default\\main\\my_branch_name\\WORKAREA\\work_area_name\\my_directory\\content\\$dcr_name.txt\"";
$cmd = "E:\\iw-home\\bin\\iwgen ".
"-t $pt -r $dcr_path $output";
`$cmd`;

}

]]></iw_perl>

ohkal

I guess I have convoluted this thread by slightly changing the subject from the original person's question who wanted to output text. Basically I just want to create one output, which is xml, but I want it to look exactly the same as the DCR xml. I prefer not to write a PT to translate the DCR into a an xml file that would look exactly like the DCR itself. I would rather just dump the contents of the DCR, tags and everything, into the output.

Migrateduser

I believe you could use iwov_xslt (maybe you actually do want to remove the broken DTD reference?). Just happen to have something like this lying around (but not sure exactly how this will work for you, if you have to copy the DTD or the DCR around to fix the broken reference, etc.).

<iw_perl><![CDATA[
my $current_dcr_name = iwpt_get_dcr_name();
$current_dcr_name =~ s,.*WORKAREA/[^/]+/,,;
]]></iw_perl>
<iwov_xslt xsl_file="/path/to/file.xsl" mode="ptlocal"><iw_include file='$current_dcr_name'/></iwov_xslt>

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl Smiley Surprised

utput method="xml" indent="yes" omit-xml-declaration="no" />
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

Adam Stoller

If your portal developers can handle the "iwov" style XML of the DCR - then that's fine. My comment about not using it was based on the fact that it tends to be somewhat overly generic as far as XML and thus not always useful for being interpreted by another application - but that is apparently not a problem here.

The other issue requires understanding where/how/when you want to make this copy of the DCR (and whether you really need a copy, as opposed to just using the actual DCR)? If you can supply more context regarding the process that you're developing it will be easier to suggest potential solutions.

The PT route is relatively simple if you were going to be going through a generation process anyway - the code for doing it would probably be similar to, though not necessarilly the same as what SMB suggested:<iwpt name="copy_dcr"/>
<iw_perl>
use File::Copy;
copy(iwpt_get_dcr_name(), iwpt_get_ofile_name());
</iw_perl>The above is untested, but I believe it will accomplish what you want and since it results in the creation of the specified ofile, the EA's should probably get set on it automatically.

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

StockChart.zip

Migrateduser

I'm not sure that would work - wouldn't the output file get overwritten with no data (after the copy iwpt_compile.ipl would flush)? But there does seem to be an alternative to the XSL solution I suggested in another post - just read the content of the iwpt_get_dcr_name() (actually the entire string may already be in memory) into ${content}, then:

iwpt_set_ostream_data( 'default', ${content} );

as the last <iw_perl> in the TPL.

Adam Stoller

As I said - it was untested - and part of what I wasn't sure about was whether or not the ofile would get overwritten, but your adaptation sounds like a reasonable approach if mine doesn't work - putting it altogether would be:<iwpt name="copy_dcr"/>
<iw_perl>
my $content = '';
my $dcr = iwpt_get_dcr_name();
if (open(IN, "<$dcr")){
local $/;
$content = <IN>;
close(IN);
}
iwpt_set_ostream_data('default', $content);
</iw_perl>Still untested - try either/both and let us know if they solve your needs.

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

gzevin

I am not always quite sure why such files should have templating attribuest... What use would they have? Maybe, to regenerate?.... But still, this could pose more issues than it solves...

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

Leo

Thanks fish!

I will try this option out.

- Leo

Leo

Hi Luke,

I tried your way with some modifications and it works. Thanks. But, the alignment of the text is totally scrabmled in may palces. Also, when I replace the <br> tag with the \n it takes 2 line space. Any fix?

Thanks.

- Leo

Migrateduser

John.

I am agree with Stefan's post.
in the templating.cfg, if you will give the output type, hope it will work perfectly.

It is untested, and shd work.

Thanks
Rishi Gupta
Interwoven Certified teamsite consultant
Satyam computer services limited, India

Adam Stoller

The purpose of having the TST EA's on the *copy* of the DCR is so that if someone attempts to edit the *copy* (through the GUI) they are taken, instead, to the Edit DCR to edit the *original* - without the EA's they would be editing a stand-alone XML file which (from what I can tell) was meant to be "derived" from the DCR and it would break that relationship and be overwritten the next time the DCR was processed to create a new copy.

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

ohkal

Thanks for all the input.

The iwpt_set_stream_data() did the trick to create the proper xml output file.

There is just one issue now. Once the file is generated, the browser displays the following error:

The XML page cannot be displayed
Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.

--------------------------------------------------------------------------------

The system cannot locate the object specified. Error processing resource 'http://houebiz275/iw/cci/meta/no-injection/iw-
mount/default/main/myportal/customer_content/pe/WORKAREA/content/contents/Overview/web/dcr4.5.dtd'.

Any ideas on how to fix the browser display of the generated file or how to make it show a simple confirmation message or nothing at all?

Migrateduser

Strip the DTD reference from the XML before iwpt_set_stream_data (using Perl substitution), or use the XSL technique.

Adam Stoller

Your browser is complaining because it cannot find the DTD that is referenced in the DCR - in the location where it expects to find it.

I believe there are several alternatives here - but I think the best one is to either remove or modify the DOCTYPE in the XML ($content) before you do the iwpt_set_ostream_data() call - something like this:$content =~ s|^<!DOCTYPE[^>]+>||s;or perhaps this:$content =~ s|"(dcr4\.5\.dtd)"|"/iw/$1"|s;The latter requires that you copy that file from iwhome/local/config/ to iwhome/httpd/iw/.

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

Migrateduser

> $content =~ s|"(dcr4\.5\.dtd)"|"/iw/$1"|s;

Can you explain how this works? I thought SYSTEM DTD reference would always look for DTD relative to XML location - this looks more like a URL, but you don't specify protocol or change SYSTEM to anything for which I would expect a system to retrieve from a URL. I'm not saying it wouldn't work, just that I don't follow. Have you done this?

Adam Stoller

No - I haven't done it - I just recall that being a "solution" some time back - but I might have missed some other steps (like changing SYSTEM to something else).

I'd generally opt for method 1 - and just strip the whole thing out as you probably don't need it for your purposes. ['you'/'your' being generic, not specific]

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