tags:

views:

111

answers:

3

Hi all, I need a sanity check on my strategy to best fulfill the requirements of a project. Basically I have an xml file that will need to be parsed periodically and html output displayed (xslt is not an option).

My thought is that I can use a single .jsp page to check an application variable that stores the last parsed date to know if it's 'time' (x days have passed) to re-generate the file. If it is, I can parse the xml via jsp and write the results to a static html file which is then dynamically included into the same jsp for rendering, if not I skip the regeneration and simply include the html file. including the html file rather than just rendering the display is to save the response / processing time for subsequent visits.

My question is whether this is a smart way to go about things, my specific concerns are 1) will I be able to overwrite an html file that may or may not be in use by visitors and 2) will the dynamic include via jsp work this way without a page redirect.

Thanks in advance for any thoughts and enduring the long post -

b

A: 

Doing the XML generation (translation) in a Servlet might make more sense. I say this because you'll most likely have a bunch of Java code. The Servlet is probably more appropriate than a JSP for a bunch of programmatic processing.

Steve Kuo
Understood, technical requirements would make keeping this in a jsp better, can't I simple declare the class inside the jsp via <%! ? Does the overall theory hold water however?
WillyCornbread
A: 

Why not simply include the JSP itself? If the JSP happens to "cache" the XML in a static file, then so be it, but just be conscious that there will be a race condition (unless specifically handled) if the JSP is called twice while it needs to regenerate HTML file.

But, at a minimum, this way the "clients" of the JSP aren't exposed to its "caching" mechanism (which happens to be an HTML file).

You could, for example, just create a new HTML file every time, and store its name in the application context, or whatever, thus you never overwrite the file. You could cache it RAM, you could not cache it at all!

The point being that the client only know about the JSP, and don't care how or why it creates the HTML, which is as it should be.

Will Hartung
+1  A: 

I'd use a cache (eg. ehcache) to store the generated html, with the required ttl.

Rendering could be handled by a servlet (you could use a jsp, but cleaner in a servlet) which would lookup the html from the cache, and simply return it as the response. If the html was not in the cache, either because it had not been generated or it had expired then it would get generated and stored in the cache.

The generation of the html from the xml could even be handled by a separate thread to avoid any delays to the user while it was being generated.

objects