August 13, 2007, 05:38 PM
<JimW>Thanks for the reply Prarie.
What we're doing is streaming report content directly to the browser rather than saving it to disk.
In that case we would need the unique report file names each time so that one user would not clobber the other's report content by using the same report file name.
The problem is that EXPIRE_REPORTS being set to 300 seconds causes a new PDF report file to be cached after 5 minutes, and the content is stored in the Temporary Internet Files folder on the client.
We don't control the EXPIRE_REPORTS setting (we are a dotNET development group using WebFOCUS), so the net effect is that we get a bunch of expired report files accumulating in that folder that may never be cleared.
We were hoping we could set a parameter to indicate the report file name we want WebFOCUS to use and it would simply overwrite the cache with that report file name; instead of generating a new one each time the cache expires.
Regards,
Jim Woods
August 16, 2007, 12:22 PM
<JimW>IBI Tech Support reply on this issue:
This has never been possible with WebFOCUS and has been requested functionality for some time. There is no workaround.
August 16, 2007, 10:44 PM
susannahi wonder if the random variable trick would work? (for the cacheing part of the problem..not the naming) this is a very interesting problem...
and i will have the same one soon , as my current client is pdf-intensive.
in html, if you use a random variable as a parameter in your fex, then the 'page name' (full url with fexname and parms) is never the same as the ones run just before it...
but that's an html trick.
(See how if you 'Publish' a fex from mre, you'll see that ibi random variable in the launch page? )
I wonder if some form of the same technique would work with pdf?
wait..here's another idea...if you bring up the pdf in a frame of a frameset, the user never sees the icky pdf filename, but is still able to click on the pdf buttons to save, email, print, whatever...that is if you have Adobe 8 reader...its quite nice.
August 16, 2007, 11:10 PM
dhagenThe way I see it, you have two things that you are trying to do here:
1) Enter a custom name for your PDF.
2) Prevent the users cache from getting full.
The first one can be resolved by implementing the same type of custom web application filter much like I suggested for opening multiple excel files. The issue there was the name of the excel file was interpreted as WFServlet, so by making that name unique, we were able to open multiple excel files at one time. The same type of technique could be implemented to allow a parm to become the pdf file name.
The second problem can be resolved right now! IE's cache would currently be filled with a pdf reference with the entire query string that is the pdf postback. Look into your cache and you'll see what I mean. If you edit the appropriate wfs file, you can change the java script function to parse the query string and build a form with a post method. When that happens, IE will force the cached file reference to be called WFServlet.pdf or just WFServlet. Therefore every pdf you retrieve will overwrite the current one that is already in the cache. The only issue here is that the current java script function uses a location.replace when calling the querystring. A location.replace is suppose to replace the current browser history file with the one that is being called. Now we all know that IE will only respect the location.replace if the called querystring returns html. When a non-html file is returned, then IE does not perform an actual replace on the history .... thus the back button problem with excel and pdf's. I guess what I'm trying to say here is that for those of us using IE, there would be no change in the user's experience, but for those of you who use other supported browsers that support the location.replace as documented, you would now get the back button issue we all know and love.
I haven't tested any of this yet, just thinking about it. Anyone out there want to give it a try?