Regenerate output files based on XSL templates

Hi there,
this is with TS 6.7.2 on Solaris 10.

I am creating a workflow which at some point has to regenerate one or more output files (depending on the number of files attached to the workflow). Since we are using XSLT-based templates, the only way to accomplish this seems to be the "urlgenerate" command.

Before creating a workflow task I wanted to try to use this command manually.
However, when I create such a URL and enter it into my browser's address field, I get a small popup error window, saying:

The passed in dcr vpath is incorrect

Which seems to be an incomplete message to begin with.

Also, the overwrite=true parameter does not seem to have any effect. If the file specified with the output URL parameter exists, the error popup message says:

Output file already exists. If you want to override it, set "override=true" in the url.

When I follow this suggestion, the same error message appears.

My URL looks like this:

https://servername/iw-cc/urlgenerate?dcr=/store/main/branch/WORKAREA/workarea/templatedata/category/datatype/data/dcr.xml&pt=/store/main/branch/WORKAREA/workarea/templatedata/category/datatype/presentation/template.xsl&output=/store/main/branch/WORKAREA/workarea/outputfile.jsp&overwrite=true

Any suggestions?

PS: Since the workflow might need to regenerate more than one file, what kind of task (if any) would be suitable to call a URL? If "iwregen" worked I would have an loop over the files and regenerate each of them, but that is unfortunately no option with the XSL templates.

PPS: In this thread (http://devnet.interwoven.com/forums_vb/showthread.php?t=25619&page=3&pp=10) LooseCannon says that

Calling the compiler ($iwhome/httpd/webapps/content_center/WEB-INF/lib/bsf.jar org.apache.xalan.xslt.Process) directly is a viable workaround.

Could this be done from an ? If so, how would I have to call the compiler?

Find more posts tagged with

Comments

RonaldV

Hi Tobias,

how are your doing these days?

To answer your questions. I think Iwov has done a bad job in the support ofXLST templates. That is, they work just fine but we, developers, miss a lot of the tools that we had access to in old-fashioned tpl's (f.i. I don't think that 'Regen file' on the Teamsite-gui-menu works on xsl generated files.) See f.i. this discussion: http://devnet.interwoven.com/forums_vb/showthread.php?t=27797&forumid=13

However using xalan from the commandline as you mentioned should work just fine. It would come down to something like this (instead of iwregen):

java org.apache.xalan.xslt.Process -IN foo.xml -XSL foo.xsl -OUT foo.out

The xalan-jars should come with teamsite, all you need to do is make sure they are in your classpath. For more details see:

http://xml.apache.org/xalan-j/commandline.html

You still work for Iwov? If yes, maybe you could use your power to make Iwov understand that they should better support and document these features.

See you, Ronald

tobias

Hi Ronald,
thanks for the advise. The CLASSPATH did the trick.

Before invoking java on the command line I now set the CLASSPATH environment variable to <iw-home>/cssdk/ssj_653/lib/xalan.jar and exported it.
In my <externaltask>'s Perl script it was sufficient to set the $ENV{'CLASSPATH'} variable to this value; no export was necessary.
After this it worked like a charm.

PS: I'm not working for Interwoven anymore, thus no power ;-)

Jcse

Hi Ronald,
thanks for the advise. The CLASSPATH did the trick.

Before invoking java on the command line I now set the CLASSPATH environment variable to /cssdk/ssj_653/lib/xalan.jar and exported it.
In my 's Perl script it was sufficient to set the $ENV{'CLASSPATH'} variable to this value; no export was necessary.
After this it worked like a charm.

PS: I'm not working for Interwoven anymore, thus no power ;-)

Hi

This is an suggestion,why don't you use URLExternal Task and called a Java Custom Code which will take xslt template and the multiple DCR's (xml) and finally generate the page.

just an approach !

thatfish

Thanks for the above guys - very useful and I've implemented a URL Task. All is fine.

For a content migration exercise I'd like to use a trusty perl script and I'd expect the following command line to work:-
java -cp /interwoven/iw-home/lib/xalan.jar org.apache.xalan.xslt.Process -IN /default/main/eCommerce/CN/zh_CN/WORKAREA/editorial/templatedata/ecommerce/storefront/data/guppy -XSL /default/main/eCommerce/CN/zh_CN/WORKAREA/editorial/templatedata/ecommerce/storefront/presentation/default.xsl -OUT /default/main/eCommerce/CN/zh_CN/WORKAREA/editorial/htdocs/en_CE/niceFish.html

However, the XSLT parser is complaining about the dcr4.5.dtd as follows:
(Location of error unknown)XSLT Error (javax.xml.transform.TransformerException): java.io.FileNotFoundException: /default/main/eCommerce/CN/zh_CN/WORKAREA/editorial/templatedata/ecommerce/storefront/data/dcr4.5.dtd (No such file or directory)
Exception in thread "main" java.lang.RuntimeException: java.io.FileNotFoundException: /default/main/eCommerce/CN/zh_CN/WORKAREA/editorial/templatedata/ecommerce/storefront/data/dcr4.5.dtd (No such file or directory)
at org.apache.xalan.xslt.Process.doExit(Process.java:1153)
at org.apache.xalan.xslt.Process.main(Process.java:1126)

Other than nasty hacks like sym links to the DTD, any ideas on getting the above to work without the Xalan Parser complaining about the DTD ?

CRB

could you post your DCR? r u using xml DCRs or iwov?

thatfish

DCR File attached and IWOV format

the following line is the culprit:

DOCTYPE record SYSTEM "dcr4.5.dtd"

CRB

do you have dcr4.5.dtd under /iwhome/local/config?
does your xalantransform work with DCRs created on 6.7.2 using the same syntax/code?

Adam Stoller

However, the XSLT parser is complaining about the dcr4.5.dtd as follows:
(Location of error unknown)XSLT Error (javax.xml.transform.TransformerException): java.io.FileNotFoundException: /default/main/eCommerce/CN/zh_CN/WORKAREA/editorial/templatedata/ecommerce/storefront/data/dcr4.5.dtd (No such file or directory)
Exception in thread "main" java.lang.RuntimeException: java.io.FileNotFoundException: /default/main/eCommerce/CN/zh_CN/WORKAREA/editorial/templatedata/ecommerce/storefront/data/dcr4.5.dtd (No such file or directory)
at org.apache.xalan.xslt.Process.doExit(Process.java:1153)
at org.apache.xalan.xslt.Process.main(Process.java:1126)

Other than nasty hacks like sym links to the DTD, any ideas on getting the above to work without the Xalan Parser complaining about the DTD ?

Generally, your choices are:

I think the first way is simplest (copy or symlink) and least error-prone.

thatfish

Thanks for your responses:-
Yes the dtd is in the right location (iw-home/local/config)
I'm on a 6.7.2 Linux environment.

I guess I'm curious that the "URL Task" and "urlgenerate" command work OK. Yet the command line is failing with the DTD error.

All three are using the same XSLT processor under the bonnet. Therefore the URL Task and urlgenerate must be managing IWOV DCRs and it's DTD path programatically and was hoping there was a simple way e.g 'an argument' to get the processor work on the command line for IWOV DCRs. There does not seem to be one on the Xalan site.

BTW - agree with ghoti comments

Update - the plot thickens
The command line is working with a workaround of copying the dtd, however, all the usual EAs I'd expect to see against the generated file are missing. So I am having to manually apply the following EAs !
TeamSite/Templating/Encoding:
TeamSite/Templating/PrimaryDCR: en_CE/test4
TeamSite/Templating/PrimaryDocumentType: ecommerce/storefront
TeamSite/Templating/PrimaryPT: default.xsl

May have to use urlgenerate and LWP in the migration script

thatfish

Update to the update:

I think I rememeber somewhere reading about an issue with where the XSLTPTCompiler is set in the templating.cfg. When I placed it at the templating node of templating.cfg and the EAs are now being set properly.

templating prune-missing-files="f" ptcompiler="com.interwoven.ui.formspub.utils.XSLTPTCompiler"

Still have to copy the DTD though.

CRB

Update to the update:

I think I rememeber somewhere reading about an issue with where the XSLTPTCompiler is set in the templating.cfg. When I placed it at the templating node of templating.cfg and the EAs are now being set properly.

are you saying that the xalanTranform cmd is setting the EAs for you??

thatfish

Apols, got in a befuddled state of mind earlier today.

The EAs are not being set although I was expecting them to be set thus my confusion.

Therefore the behavior is as I would expect.

CRB

The EAs are not being set although I was expecting them to be set thus my confusion.

yeah that is the expected behavior from the XalanTransform since it is just the public version. EAs have to be set manually which is what you already did.

jasonmcneil

My URL looks like this:

https://servername/iw-cc/urlgenerate?dcr=/store/main/branch/WORKAREA/workarea/templatedata/category/datatype/data/dcr.xml&pt=/store/main/branch/WORKAREA/workarea/templatedata/category/datatype/presentation/template.xsl&output=/store/main/branch/WORKAREA/workarea/outputfile.jsp&overwrite=true

Any suggestions?

For anyone else out there who stumbles on this thread, the last parameter should be override, not overwrite. Also is there any documentation about this URL command anywhere?

Migrateduser

I am having a similar issue. We are using tpls and just started creating xsl so we'd like to generate both. When I add the compilier to templating.cfg a single page generates just fine. When we use command line to regen an entire branch the pages with xslt fail and we end up with blank pages. I learned that the command line ignores templating.cfg

This is what our webmasters are essentially calling when they regen a branch:
command=D:\iw-home\iw-perl\vendor\lib\TeamSite\SH\regenDir\runRegenCmd.ipl Y:\default\main\ts.internet\site.org\site.org_Live\WORKAREA\site.org Y:\default\main\ts.internet\site.org\site.org_Live\WORKAREA\site.org\htdocs\contact

This in turn basically cals another file that runs iwregen on each file in the directory or branch as needed.

How can I add the compilier to this process to generate both? I am assuming that I would include the path to xalanTransform somewhere.

Thanks!

kalai

What ever the output files you have generated using the TPL will have the extended attributes PTName as ****.tpl name.After converting all your TPL based templates as XSL template then you have to do below steps.
1. Change your EA's to point your XSL file name instead of TPL name(Write a script to do this)
2. Change your Per PT compiler to XSLT PT compiler in templating.cfg

Do you want to generate the output files using TPL as well as XSL?

Adam Stoller

The choice between TPL and XSL for a given data-type (DCT) - via the GUI at least - is "either or" - not "both".

The command line tool used to generate pages from XSL is distinctly different than the command line tool used to generate pages from TPL - thus, your script would need to know which command line tool to use on a data-type by data-type level, or as a flag to your script to instruct it to use one or the other -- or -- if you only have either

presentation/*.tpl

presentation/*.xsl

files, the script could make a logical determination as to which CLT to use based on the PT extension.

Migrateduser

I see how I was not clear in my previous post. We have branches that contain pages that generate using old tpls and new pages that generate using xsl. No pages are both just one or the other, but branches contain both. So we need them to be able to (within a few clicks) regen their branch that will have pages that are regenerated by xsl OR tpl.

So from what I gather we'll have to write some logic that determines which type is being used for that particular page and call it.

Would that flag be contained in EA or....

I am guessing that I need to call in the compilier in there somehow. xalan

Thanks!

Adam Stoller

I see how I was not clear in my previous post. We have branches that contain pages that generate using old tpls and new pages that generate using xsl. No pages are both just one or the other, but branches contain both. So we need them to be able to (within a few clicks) regen their branch that will have pages that are regenerated by xsl OR tpl.

So from what I gather we'll have to write some logic that determines which type is being used for that particular page and call it.

Correct - either by parsing the templating.cfg file or by ensuring that your presentation folders contain either TPLs or XSLs - but not both and then just checking the contents of the DCR's associated presentation folder (it's much easier if you only have one PT per data-type - as you'll know what to use for the PT argument; if you have more than one PT you'll have to build in more logic to determine whether to cycle through them or use one over another, etc.)

Would that flag be contained in EA or....

Well, if you start from the generated pages rather than from the DCRs - and the pages were generated "properly" - there are EAs that indicate the DCR and the PT used to produce the page (that's how iwregen works/worked).

I am guessing that I need to call in the compilier in there somehow. xalan

Thanks!

Yup. Good luck, and if you are so inclined, it would be nice if you posted some of the details of your resolution once you get there.

Migrateduser

So I have tried about a million ways to get this to work through trial and error. Suffice to say I have written perl to determine by EAs which command to use to complie a page.

I can successfully regen pages of xsl and tpl in the same folder, but I am getting some errors. This is mostly based on context I believe. When I regen from UI it works fine as we are using the iwtools to getArea() to build nav and other items. The command line chokes and spits out an error like this:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.xalan.extensions.ExtensionHandlerGeneral.(ExtensionHandlerGeneral.java:229)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.apache.xalan.extensions.ExtensionNamespaceSupport.launch(ExtensionNamespaceSupport.java:93)
at org.apache.xalan.extensions.ExtensionsTable.(ExtensionsTable.java:64)
at org.apache.xalan.transformer.TransformerImpl.setExtensionsTable(TransformerImpl.java:441)
at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1323)
at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:709)
at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1284)
at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1262)
at org.apache.xalan.xslt.Process.main(Process.java:1046)
Caused by: org.apache.bsf.BSFException: JavaScript Error: Internal Error: org.mozilla.javascript.EcmaError: TypeError: getContext is not a function.
at org.apache.bsf.engines.javascript.JavaScriptEngine.handleError(JavaScriptEngine.java:195)
at org.apache.bsf.engines.javascript.JavaScriptEngine.eval(JavaScriptEngine.java:147)
at org.apache.bsf.util.BSFEngineImpl.exec(BSFEngineImpl.java:141)
... 17 more

The offending line from iwtools.xsl is:
var xslContext = Packages.com.interwoven.cssdk.transform.XSLTExtensionContext.getContext();

right now from the command line I pass the param to get the workarea, but if I don't use iwtools the page cannot get the area from the ui unless there is another way I don't know of in the xsl itself.

The command I am running is:
`D:\iw-home/tools/java/bin/java.exe -cp "d:\\iw-home\\httpd\\webapps\\content_center\\WEB-INF\\lib\\bsf-2.4.jar;d:\\iw-home\\httpd\\webapps\\content_center\\WEB-INF\\lib\\commons-logging-1.1.jar;d:\\iw-home\\httpd\\webapps\\content_center\\WEB-INF\\lib\\js.jar" -IN "Y:\default\main\ts.internet\test.org\test.org_Live\WORKAREA\test.org\templatedata\health/dynamicSubPage\data\serology_testinfo" -XSL "Y:\default\main\ts.internet\test.org\test.org_Live\WORKAREA\test.org\templatedata\health/dynamicSubPage\presentation\xsl_HTML_test.xsl" -OUT Y:"Y:\default\main\ts.internet\test.org\test.org_Live\WORKAREA\test.org\htdocs\serology\xslTest\xslTest2.html" -param gA Y:\default\main\ts.internet\test.org\test.org_Live\WORKAREA\test.org 2>&1`;

The param gA is what is giving me context for the navigation that is needed.

Any help is mucho appreciated.