Inline calling XML with an Inline

TS552, Solaris

Hi,

We have a very complicated/big branching structure where we are usign the same DCT in multiple places. So far everytime we make a change we have to recopy all these DCTs to their locations - and this takes a lot of time!
What we have come up with though is to have a DCT that is just a wrapper with an inline command:

<inline command="cat /path/to/my/temp.xml" />

This works fine and is great except that in our temp.xml - which is standard DCT xml - we have more inline commands. These inline commands are used to populate option menu's. Again just using a command similar to the above. However it seems that these inline commands do not get called so the drop down options are empty.

Does anyone have any idea's about how we can ensure the inline is executed?

I have attached a zip file with all the files we are calling.

Any suggestions would be great.

Thanks,
Jeremy

Find more posts tagged with

Comments

Adam Stoller

The inline command has never supported recursive processing.

You could try writing a script that pre-processes your initially inlined file to recursively process inline statements and eventually return a fully evaluated inline XML string to the DCT - or you could break up your initially inlined file into separate components, each of which get inlined directly from the DCT.

If you're comfortable with XML parsing and programming - the first solution shouldn't be too difficult (but will take some time to design/write/test.

If not - you're better off with the second solution - which requires you to plan out your inline'd code so that it can be broken up in such a way as to avoid ever having nested inlines.

--fish
(Interwoven Senior Technical Consultant)

james1

You could also just use some macro language to generate your DCTs for you. It would be much more efficient for you to have pre-generated static DCTs, versus dynamic DCTs that have to execute a number of inline callouts each time the DCT is accessed. The GUI will be much more responsive that way.

-- James

--
James H Koh
Interwoven Engineering

gzevin

one partner of the client of mine did an implementation when they did mimic the behaviour of the inline command - something like what is described above. It works fine....

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

Jeremy

Thanks for the idea's guys.
We wrote a short perl script that is called by an inline command. It reads in the required XML file - checks for any inlines which it executes and inserts thier output back into the XML it returns.

One thing I we have noticed though is that if our inline commands are shell script they execute a lot fastre than a perl script! The differece in performance this has made in our environment is unbelievable! So I will probably be trying to convert my Perl script into some form of Shell script now!

Just something to remember.

Jeremy

Adam Stoller

It may be the overhead cost of starting Perl - it may also have something to do with the way the Perl scripts were written. Though not involved in 'inlines' - last year I worked on a project where I was able to clean up Perl scripts used in a customer's workflows and achieved a 60% improvement in performance from that alone!

See Article 48909 for related information....

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

We are having the same problemas you had mentioned.
This was a very informative post.Thank You.Iwas wondering if you could share your script that did the retrieving of the nexted inlines.
Thanks
Shay Reddy

Migrateduser

In the past, when I have run into start-up cost problems with perl, I have used speedy, which keeps perl scripts persistant. I think it is a similar concepty to fast CGI. So, if it is too painful to go with shell scripts, you might want to investigate it more.

I believe it only takes a few minutes to install, but after each TS upgrade, you would probably have to re-install (bummer.)

[url wrapped]
http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?new=Search;filetype=%20distribution%20name%20or%20description;site=
ftp.funet.fi;join=and;stem=no;arrange=file;case=clike;download=auto;age=;distinfo=941

From the dscription:
SpeedyCGI is a way to run perl scripts persistently, which can make them run much more quickly. A script can be made to to run persistently by changing the interpreter line at the top of the script from:

#!/usr/bin/perl

to

#!/usr/bin/speedy

After the script is initially run, instead of exiting, the perl interpreter is kept running. During subsequent runs, this interpreter is used to handle new executions instead of starting a new perl nterpreter each time. A very fast frontend program, written in C, s executed for each request. This fast frontend then contacts the persistent Perl process, which is usually already running, to do the work and return the results.

--
Jed Michnowicz
Interwoven Technical Consultant

Adam Stoller

I've been interested in looking at speedy for a while - but haven't gotten around to it. A few questions come to mind though:
1) Does speedy work on Windows or just on Unix?
2) Does speed work with Interwoven Perl modules (i.e. I don't want to have to put a whole bunch of 'use lib' or 'push(@INC, ...)' statements in each of my perl scripts)

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

1. Dunno. I only have solaris clients Smiley Happy

But, it does not look like a win32 binary of speedt is provided. (http://daemoninc.com/SpeedyCGI/CGI-SpeedyCGI-2.21/binaries/)

2. I have not used speedy for about 18 months, so this is just an education guess, but.....

With speedy, you do not need to use the speedy supplied module to do most things. You just change the shebang to use the 'speedy' binary, which is a lil' C program.

The FAQ contains instructions that tell you how to edit the makefile to install the speedy binary to a new location. So, between iwov upgrades, that would lead me to believe that speedy would still work if it was installed to "$iwhome/custom/bin/speedy". If the version of iwperl was upgraded, speedy might have to be recompiled.

Usually with speedy, most problems are with global variables.

From the FAQ
>>>
Install in a Different Directory

* Edit src/optdefs and change the default value for BackendProg to the location where speedy_backend will be installed.

* Compile as above, then manually copy the speedy and speedy_backend binaries to where you want to install them.

* If you want to use the CGI: Smiley Frustrated

peedyCGI module in your code (it's not required), you will have to use "use lib" so it can be located.
<<<

PS:
I should also note that speedy is changing its name to PersistentPerl.

--
Jed Michnowicz
Interwoven Technical Consultant