Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Finding the name of the generated html
prasadanand
Hi I am using a dcr (x.dcr) and a tpl (x.tpl) to generate an hmtl (x.html) and this is done manually and send the generated html file to the approver.
For me the task is done if i can find out the name of the html and its path through a script.
is there any method or command i need to use to accomplish this. this way if i obtain the generated html path and name i can attach that file and send it for approver.
if i generate multiple html files out of the single dcr is there a way i can retrieve all the html files that are created with the dcr?
thanks in advance
Find more posts tagged with
Comments
Adam Stoller
Why don't you do the generation of the file within the script rather than outside the script?
If you do that, you already know the path/name of the generated file.
--fish
(Interwoven Senior Technical Consultant)
prasadanand
The users want the flexibility to go to their selected locations to generate the html files manually.. and multiple html's need to be generated out of single dcr's that i cannot do with a script presently..
Adam Stoller
Then you need a mechanism whereby the PT's register the path/name of the generated file while generating them. You could do this as EA's on the DCR itself, you could do this into a flat-file or DB too.
--fish
(Interwoven Senior Technical Consultant)
prasadanand
i am using
my $output_file = iwpt_get_ofile_name(); to get the name of the generated html file inside the pt's and setting extended attributes to the dcr ... am i going the right way..?
Adam Stoller
That's certainly a direction - the only question is: Have you planned for having multiple files generated from the same DCR? - either through one PT that generates multiple pages, or multiple PTs that generate one (or more) pages from the same DCR. If you don't need to worry about those conditions - then you're probably fine. If you do have to worry about those conditions then you need a good naming scheme for your EA's so that you can have more than one attached to the DCR to point you to the other pages.
The of course, there's the issue of cleaning up the EAs if any of the generated pages are not required anymore (but others are)... and there may be a number of other issues that you need to consider that are specific to your environment and the usage of the product within it.
This is why I strongly suggest DESIGN before IMPLEMENT. The quick implementation can give you a proof-of-concept, but before you put all your eggs in that basket make sure there aren't any holes in the design...
--fish
(Interwoven Senior Technical Consultant)
KTR
Hi,
I am planning to get multiple files generated from the same DCR? with one PT that generates multiple pages?
I would appreciate, If any one have great ideas on this.
Thanks
Adam Stoller
Do you have items/replicants setup within your DCT that define the extents of the page breaks - or are you trying to programatically determine where to put page breaks based on some algorithm?
The former requires a bit more work on the person developing the DCT and the person filling in the DCR but is relatively straight-forward for the person developing the PT, the latter requires a significant amount of work on the person developing the PT (I'm not sure it's even possible, but ...)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
KTR
Yes, I have items/replicants setup within your DCT that define the extents of the page breaks. I think I have to develop diff PTs and call that replicant section only. main PT calls the other PTs thru iw system cmd's. Pls advice me, If I am wrong.
gzevin
why don't you use iw_ostream to change output file names on the fly, till you generate all the pages?
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
Adam Stoller
As Greg pointed out - this is what I meant by it being relatively straight-forward if you already have the pagination indicated within the DCR. Personally, I find it easier to do this by writing the entire PT in Perl rather than using the XML mark-up but you can do it either way.
(there's actually a case of this kind of thing at my current customer site - left over from a previous consultant - that I'm hoping to find time to rewrite correctly using either iw_ostream or just simple open/print/close calls...
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
KTR
I would appreciate, if you post the code for ref.
Thanks in adavance.
Best regards.
Adam Stoller
I would / probably will - when I actually get to working on it - but I don't know when that will be - so don't wait on me to start working it out for yourself.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
gzevin
Adam,
for curiousity sake, if you use open/close in pure perl - will be the files generated by a PT included in the manifest of iwpt_compile?
Never tried - even though I write everything else in pure perl
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
Adam Stoller
Hmm - no idea, I'm not even sure I know what you mean by the manifest of iwpt_compile.
I do know that whether you use open/close or iw_ostream - the additional pages which are generated do *not* automatically get TST EAs associated with them - you have to do that yourself and currently it's a fairly expensive operation (3-4 calls of iwextattr per additional page generated).
I believe I have a feature request registered to get the EA thing built into iw_ostream, and I also believe that in TS6 or post-TS6 there will be a webservice interface for getting/setting EAs which should be far more efficient than the current CLT-based methods.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
Adam is correct, you can now manipulate EAs through Conent Services 2.0 and its WSDL, or through the Java calls. You can check out the CS SDK 2.0 manuals on the support site at:
https://support.interwoven.com/library/manuals/cs/cs.asp
regards,
lissa
Johnny
I wouldnt expect file open or any direct perl calls for writing files to be written to the manifest produced by iwpt_compile. (iwpt_compile can generate an xml file which lists all presentation templates used and all generated files either through ostream or ofile. Its very useful for obtaining all generated content which for example you could then attached to a task. Its essential when using ostreams in templates in conjuction with page generation via external tasks)
I think ostream would be best in most cases because of this and for its other features such a stream filters.
How you travelling Greg?
John Cuiuli
Johnny
There's another interesting point here about EAs and ostream files.
I dont think that setting EAs will always be appropriate for ostream files. Depending on your purpose and the method used, some ostream files may for example be generated from a number of DCR's or from none at all. Maybe even from another data-type. There is no real limit on what you can/should do with ostream files, which makes it harder to definately say what it should be stamped with. It will probably still useful and appropriate to some degree, but I dont think it will always be the case.
John Cuiuli
Adam Stoller
I agree - the feature request (that I think I filed) had to do with adding an attribute to iw_ostream to enablle it to set the same EAs on the seconday files as it does on the primary file generated by iwgen (of course, if you're using iwpt_compile.ipl directly - then no EAs will be written on either the primary or secondary files)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
gzevin
fish & John -
thanks for the comments while I was not on the forum.
yes, John has perfectly explained what the manifest is for
And this is why one *sometimes* needs to use iw_ tags
John, I'm back in Sydney now..
Greg
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
Johnny
Didnt know you had left!
John Cuiuli
