Using .jsp pages in preview (not a content item)

I want to embed(using javascript) the content of a blog into several pages of a new site I am setting up. Due to cross site scripting restrictions (the blog is on a different domain) I can’t get the XML feed directly… so I have built a “relay” script in PHP for my live server which is basically a LAMP setup. However, this relay script won’t work in preview because Tomcat doesn’t interpret PHP. I thought it would be simple enough to re-create this script in .jsp, then use a publishing variable to switch between the two scripts, however, when I create a .jsp file in my web_resources directory and try to access it from a browser, I get a 404 error. As far as I know my server setup is pretty much default… a 5.x system that was upgraded to 6.5.2. If I change the extension of the file to .html it spits the file out beautifully. I have poked around in the web.xml file a little but to be honest I don’t really know what I’m doing with Tomcat so I’m not sure what to look for. Shouldn’t this be working by default or is there a simple change to get it to work with .jsp files? Does it matter that I’m doing it as “site furniture” rather than an actual CMS content item? From reading the forums it looks like some people are running .jsp pages out of the publish, so how does preview work for them? I could try setting up these scripts in some kind of template, so it publishes them as actual CMS items, but before I invest a lot of time on that, I thought I would ask here first.



Not quite answering your question, but why don’t you have your relay script spit out some javascript? A la the contents of the feed? It appears that you want to use javascript anyway…so…

We have a feed reader content type that behaves in this manner…the php script parses the xml and spits out javascript code…we then do a js embed of the code in the template (the src of the script tag points to the php page…)

In actuality there are two feeds that we are putting in the sidebar. One comes from a local xml file published by the CMS, there is no problem with this feed. The second feed comes from a different domain, and therefore is in need of the relay script.
I use the same javascript code to process both of these feeds and display them on the page, I have abstracted the javascript to the point that I can tell it the resource to get the XML data from, the ID of the html element to put the rendered code in, the max number of items to get from the feed and the max length of text in the summary to use. These options are needed because on the home page, The feeds run different lengths on the home page than it does on different pages, so I don’t want to hard code any of that stuff into the relay script. I tend to shy away from using document.write() as I think it is a crude implementation compared to something more targeted like innerHTML.

At any rate, I COULD potentially put a dummy XML file in place for preview purposes, but I really like the idea of getting the real feed to show up during preview. Anything to make the user more confident that what he/she sees in the preview is what will come out in the final publish.

Another good reason is that I’m using ajax calls to do this, so each feed can load independently of each other, and independently of the page they are embedded in. If for some reason the feed is slow to respond, the user doesn’t feel the lag. Using document.write() causes the browser to wait for a response before continuing.


Another approach to this would be to create an XML application in CM System to use as the preview’s relay. Your resource would be a dummy selecting from RXDUEL, and your XSL would essentially be something like:

<xsl:stylesheet version="1.1" xmlns:xsl="">
   <xsl:template match="/">
      <xsl:copy-of select="document('http://original.feed.url')/*"/>

That’s not a bad idea. Before I start going down that road however, does anyone know which web.xml file controls the settings for preview, again I’m not really well versed in tomcat stuff, but it might be that a little servlet mapping might fix this… at least that’s one idea. Has nobody else ever tried to do this? It seems like someone would have done this by now.