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)
Teamsite 5.5.2 or 6.1 and Java Support
vp98aa
Hi,
I have a fairly complex need but I am going to start off with a simple question. I have heard a lot about the backend Java support in Teamsite 5.5.2 and newer versions. Where can I find some documentation for that?
Today I have a DCT where one of the dropdown box is populated from an external XML file. The parsing of XML is done via Perl. We have some complex needs where I personally believe that Perl would not be all that efficient and the code itself would look pretty nasty and hard to maintain. Now if we have Java support, like I have heard, then that could make our life lot easier.
So bottom line question is: Can I use Java to populate a dynamic dropdown box in the DCT with Teamsite 5.5.2 or 6.x?
I would appreciate all your help.
Thanks
Find more posts tagged with
Comments
Gregg Faus
Yes. You could use a JSP as a target of a callout. Could you be doing a XSL transformation on the XML to output the substitution in the dropdown?
vp98aa
Thanks for your answer. Let me provide you more details and maybe you'd be able to help me further.
This is what I am trying to achieve in the DCT. Lets say a we have an XML file that contains documents about cars. The XML is structured by the Make and Model of the car. So, for example, we have something like this without the XML padding:
Ford
-Mustang
--MustangDocument1.pdf
--MustangDocument2.pdf
--MustangDocument3.pdf
-Taurus
--TaurusDocument1.pdf
--TaurusDocument2.pdf
--TaurusDocument3.pdf
Jeep
-Grand Cherokee
--GrandCherokeeDocument1.pdf
--GrandCherokeeDocument2.pdf
--GrandCherokeeDocument3.pdf
etc. etc. etc.
In my DCT I will have 2 dropdowns. They will be
1. Make - Listing all the companies like Ford, Jeep, etc
2. Model - Listing all the models based on what we selected for the Make. ex. Mustang and Taurus for Ford.
When the user loads the DCT, she will see 2 dropdowns: Make and Model. Once the user has selected the Make and Model, there would be another field called Documents that will be populated with corresponding document for that Make and Model.
So for example: If the user selects following:
Make: Ford
Model: Mustang
then the third field will be populated with following documents:
--MustangDocument1.pdf
--MustangDocument2.pdf
--MustangDocument3.pdf
NOTE: I know how to do all this in Perl. The example I gave above is only a small fraction of what is needed. We have noticed that Perl is taking a performance hit (bit time) to do all this because of the size of XML file. So I was wondering if there was a way to do this via Java since IWOV folks claim to have all kinds of Java updates to the backend.
Any/All help would be appreciated.
If you have any questions please let me know and I'll try and clarify it.
Thanks
Migrateduser
If you can require all CMS clients be IE5.5 or a recent Mozilla, you can just have the browser do the XML parsing in JavaScript (offload to the client). The file would have to be available over http (for instance, in IWHOME/httpd/iw/custom). Is that an option for you?
vp98aa
Hi,
Well requiring a standard IE 5.5 or better is definitely doable. Can you elaborate on how it would be done? Though I would guess that any client-side processing would take a fair amount of performance hit?
Are there any other backend or server-side options? Doesnt IWOV claim to have all this Java support on the backend or is it just bluff?
Thanks
Migrateduser
You probably have to take the performance hit somewhere and I generally prefer to offload to clients when possible - server has performance problem of collecting data, client has performance problem of parsing data. You can use Java to populate drop-downs in at least two ways, inline or JSP. JSP is better because then you don't have to set up classpath and fork a JVM on an inline command line (usually with a Perl wrapper - yuck), but then you have to use callServer to invoke it and it's generally best to avoid asynchornous callServer, especially generation of JavaScript to execute in the parent (DCT) window. I have what I consider an awesome solution to this whole problem if the clients can all handle XML with JavaScript - have the JSP generate XML and use the clients XML parser to handle it. Basically I think anything that would normally be done with inline and/or callServer can be done with this approach with fewer defects, better performance, more dynamic interaction and code that is easier to follow. I was going to write an article on this some time ago but then I thought, what incentive do I have?
vp98aa
Can you provide a detailed example of what you are mentioning? Have you done this and did the size of the XML hampered the performance?
Also I'd like to know what about Interwoven's support for backend Java? I mean they were saying that almost anything that was doable in Perl would be doable in Java in the new Teamsite version?
Thanks.
Gregg Faus
For a pure server-side solution I'd recommend the following:
1) Using FormAPI and add onchange handlers to both dropdowns (make/model).
2) Wire up the onchange event handlers for each respective dropdown to use a
callServer
FormAPI call to get the resulting dropdown for the next drop down. For example, for the Make, you'd call this method with the currently selected Make and then server (see #3) would return the Models available. Use this list to dynamically populate the Model dropdown (using the addOption method).
3) Create a JSP/Perl script on the server to accept a model or make querystring parameter. Use this parameter in a XPATH statement to get a list of applicable nodes. Iterate or nodelist and return a string to the callee.
That is a basic algorithm you could use. The client-side approach would work as well, but that would require the user to download the entire XML document. My approach doesn't.
vp98aa
Hi Gfaus!
That sounds like an interesting solution. How do you call a JSP from a DCT? Is it the same way as an IPL (IWOV Perl file) or CGI file?
Thanks.
Migrateduser
I don't have time to put sample code together right now, but I have used this approach for large-scale implementations. In fact it might be easier to demo in person - are you in the bay area (no I am not looking for a new contract). In general, the larger the document, the worse the performance gets, plus IE seems to have memory leaks. So maybe the JSP could filter the XML down (pass some query parameters). I generally use lazy initialization and cache the results to help with performance, but it's never been so bad that I reconsidered the approach.
Migrateduser
Interwoven's claim is that anything that can call a command line has an API to TeamSite. Forking every time you need to access the system is a great API - it really takes a load off the server. It's kindof like stopping your car at every light, turning it back on, turning it off at the next light, etc. Saves a lot of gas. Also good for security when you're creating command lines from CGI query parameters.
I think what the engineers probably intended (that marketing went nuts with) is that as of 5.5.2 you have ContentServices and OpenAPI which both support Java. But like I've said many times before, since not all processes have authentication information your higher-level Java APIs will probably abstract the lowest common denominators : the CLTs.
vp98aa
Thanks Jimmy for your feedback.
I like how you put it: "Marketing went nuts with" Teamsite engr's original intentions.
Thanks and I think I've got enough to get started on this and if I run into something fruther then I'd be back on here.
vp98aa
Well I am back sooner than I thought.
The question I have is can we call a JSP from DCT the same way as we call Perl/CGI scripts today? or something different?/
Thanks
Migrateduser
You can't call a JSP with an inline - you would have to fork a JVM. You can only call the JSP using callServer or XML/JavaScript.
vp98aa
Where can I find more documentation on that or perhaps and example? I dont know much (almost nothing) about callServer.
Thanks.
iwovGraduate
kb #48946:FormAPI - Introduction and API Reference
There is also a FormAPI Developer's Guide (pdf) on support site along with documentation for TS 6.x
Migrateduser
http://<hostname>/iw/help/tst/formapi/formapi_28.html#IDX14
Where <hostname> is a TeamSite server, for instance
http://cms.monash.edu/iw/help/tst/formapi/formapi_28.html#IDX14
. But like I said, be careful or avoid using it at all if possible - it can result in bugs as JavaScript is executing in one browser frame, interacting with objects in or calling methods of objects in another frame, which can cause synchronization bugs and makes code difficult to follow. You can embed all the logic in FormAPI...
vp98aa
Ok I got the callServer to get to the JSP. But I am having trouble with setting the value of DCT fields from that JSP.
This is what I have in the JSP:
<script language="javascript">
-function setDctFields(){
--alert("111");
--// Get handle to the FormAPI/userscript frame.
--var api = parent.getScriptFrame();
--alert("222");
--// Set the city and state.
--api.IWDatacapture.getItem("/city").setValue("Sunnyvale");
--api.IWDatacapture.getItem("/state").setValue("CA");
--alert("hello");
-}
</script>
This code didnt seem to set the values for city and state fields in the DCT. So I started debugging it and I started adding a few javascript alerts. I know the JSP is getting called as the first alert displays 111 but it doesnt go to the second alert which should display 222. So my guess is that the following code is bombing on me:
var api = parent.getScriptFrame();
This is a standard call that is mentioned in the FormsAPI. Anyone know why this would bomb on me? I tried different variations of that code like this:
1. var api = this.parent.getScriptFrame()
2. var api = form.parent.getScriptFrame()
but none of them worked. Any ideas?
Thanks
Migrateduser
code looks right to me - this is exactly what I use:
api = parent.getScriptFrame()
One way to debug - ensure your callServer is using get as opposed to post, tail -f /var/adm/iwui/access_log (or whatever), reload your DCT, see the URL of your JSP with the parameters being passed, open a new browser window, paste the url from the log after hostname, view source. The parent reference should throw an error but at least you will see exactly what code would be running.
vp98aa
Hi,
Thanks for your reply. For testing purposes I am not even trying to pass any parameters to the JSP. For now all I want is the JSP to set some variable in the DCT. But eventually I'll have to pass parameters to the JSP.
Since I am not passing any parameters, would it even matter if I used get or post? What could be wrong?
Thanks
Migrateduser
no, get or post shouldn't matter (unless you are passing many params in which case get is a problem). So you could just bring up your JSP in a browser and see what JavaScript it is generating.
vp98aa
Here is the exact code that the JSP is bringing up when I pull it up in a browser on its own and NOT via Teamsite.
<html>
<head>
<script language="javascript">
function setDctFields(){
alert("aaa");
// Get handle to the FormAPI/userscript frame.
var api = this.getScriptFrame();
alert("bbb");
// Set the city and state.
api.IWDatacapture.getItem("/city").setValue("Sunnyvale");
api.IWDatacapture.getItem("/state").setValue("CA");
}
</script>
</head>
<body onload="javascript:setDctFields();">
</body>
</html>
Any thoughts?
Migrateduser
Just the this, that could be a problem (should be parent, right?).
You could also add alert( api ) once you define and initialize - that should give you "[Object]" or whatever - if it doesn't, the call must be wrong (but I don't know how to correct it because it looked right before). But test this from the DCT, not calling the JSP directly.
Migrateduser
Hey are those things you're setting selects? In that case you have to pass an index, not the text. I posted a function that maps text to index a while ago - will search.
Migrateduser
http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEMPLATING&Number=34990&Search=true&Forum=All_Forums&Words=setSelect&Match=Entire%20Phrase&Searchpage=0&Limit=25&Old=allposts&Main=34984