Using a JSP and EL to a file or ByteArrayStream?

I need to populate a non-HTML text stream (say an email message) with data in my POJO bean. If I want to send it out to a browser, its easy. But I want the text, processed with EL, locally to the server.

The idea would be to take a JSP page as a "template" and then populate the template with appropriate EL values. This allows a GUI designer/artist to make the JSP look
as cool as they want, using tools they know how to use, and lets me, the engineer, not care about how its made pretty.

Is this possible? Any ideas on how to start?

thanks
pat

IMO JSP is a poor choice for this, but I know you can run JSPs out-of-container, because we do it in Struts 2 for testing purposes. I don't know how it was implemented, though; I know it used some Tomcat guts.

I'd aim for something like FreeMarker or Velocity, which is designed specifically to allow non-container-based templating (and it can still be used as the web view layer).

My boss wanted to do the whole project in Groovy on Grails. Apparently, they use GSP, similar to a JSP, but for Grails/Groovy. He got the idea from that.

I'll check out Freemaker and Velocity.

While I would not have picked JSP as the obvious choice, the idea that the UI/Graphics folks have to be fluent in JSP anyway, for the main web pages, so they could easily transition to using JSP for general templating does make some sense.

Lucky for me, my boss is not a complete bozo.

In another thread, long ago:

Bear Bibeault wrote:With the advent of JSP 2.0 with the JSTL and EL, the time of 3rd party template engines such as Velocity and Freemarker has passed.

If this is true, then what is the approach that I need to use?

What I meant was for rendering the view. Freemarker is a lot like JSP 2 with the EL and JSTL and I see no benefit from using those in place of JSP for rendering HTML to send to the browser.

However, that's not what we're talking about here. Back in another job, we used Freemarker to compose emails from a template. As David has already pointed out, JSP isn't intended for that and it'd be easier to use a tool that is.

Bear Bibeault wrote:What I meant was for rendering the view. Freemarker is a lot like JSP 2 with the EL and JSTL and I see no benefit from using those in place of JSP for rendering HTML to send to the browser.

Consistency, and it's still less verbose than JSP.

I can see that Freemaker is a better fit. But its not EL, the syntax is almost the same, but not quite.

Sometimes I find it easier to use two completely different languages rather than two that overlap 98% and break stuff 2% of the time. My brain can never keep that 2% difference straight.

David Newton wrote:Consistency, and it's still less verbose than JSP.

But JSP/EL is the standard. Everyone knows it, warts and all.

Sort of like the evils of Date and Calendar, Java is stuck with backwards compatibility.

David Newton wrote:

Bear Bibeault wrote:What I meant was for rendering the view. Freemarker is a lot like JSP 2 with the EL and JSTL and I see no benefit from using those in place of JSP for rendering HTML to send to the browser.

Consistency, and it's still less verbose than JSP.

Not even close to a justification, in my opinion.

If unifying all view technologies and not having to type so much isn't a justification, I don't know what is.

David Newton wrote:If unifying all view technologies and not having to type so much isn't a justification, I don't know what is.

I'm really not interested in a theological debate.

I don't see how we can use anything but JSP/EL for the main page views. Its the standard. So any solution that uses something like FreeMarker or Velocity, breaks your grand unification theory.

One size fits all really means "fits none".

Seriously, I know where you're coming from. I just don't think that using a technology like Freemarker instead of standard JSP makes sense in the general case.

Pat Farrell wrote: Its the standard. So any solution that uses something like FreeMarker or Velocity, breaks your grand unification theory.

It's the "standard" because people keep using it, not because it's the best solution.

My requirements precluded its use for a variety of reasons, including the very reason you're talking about--I had to deliver what were essentially our web pages via email. Rather than do the work twice, or resort to treachery, I used a technology supported by the frameworks I use for both web and email delivery. The decision was simple.