I am currently working on a legacy application that has a lot of the following:
show_article()
show_article() goes out, grabs the article (based on some evil global variables ;) and prints it out as it goes.
This makes it bloody hard to test, and *really* hard to cache. To handle scalability I may want to get that article and save the HTML to disk for use later, or grab the article object and put it in a distributed cache, or ….
The fact that most of the methods in this application do not return strings, but rather just go ahead and print to STDOUT makes life a real nightmare.
This is one of the pros of Velocity vs. JSP. Why can’t we create a JSP engine, setup bindings, execute, and get back a string? Then we could even use JSP outside of the web scope (e.g. to generate emails).
September 12th, 2006 at 3:09 pm
That does suck about JSP. As a workaround, you can capture the output of a JSP using a servlet filter. As for emails, if you’re generating the email in a web request, you can use a RequestDispatcher and capture the output in a string buffer.
September 12th, 2006 at 10:57 pm
What Bob said + the caching filter in EHCache (http://ehcache.sourceforge.net/)
September 20th, 2006 at 7:31 pm
I agree with the JSP vs Velocity approach, I have taken the attitude of using JSP for web and Velocity for Email also.
I really like Bob and Nicks suggestions and will be looking into them in more detail.
June 3rd, 2009 at 4:47 am
It was great to go through your post. Keep up the good work.