I'm not sure if this is what you were asking, but by adding the block
of code at the beginning of the jsp:
<%
response.setContentType("text/plain");
%>
Your test phrase (the one including <> blocks) will show up as plain text.
I have also done jsp's to appear as mp3 playlists in this fashion.
Randy Beiter
[EMAIL PROTECTED]
On Wed, 1 Sep 1999 11:12:51 -0700, Taylor Gautier <[EMAIL PROTECTED]> wrote:
>Hello. I would like to find out if anyone is using JSP to produce content
>other than HTML and XML?
>
>The reason I am asking is because there is a significant problem with the
>JSP spec w/r to other content types; even HTML content types.
>
>The problem I speak of is thus:
>
>When a bean is called upon to produce content, it generally produces that
>content as a string via a get method. This content type is text/plain.
>
>However, the output of a JSP page is generally not text/plain, usually it is
>text/html, and maybe it is something else, like say
>x-application-www-form-urlencoded (or whatever that string is, too long for
>my brain).
>
>Have you ever had a bean produce a string like "The following <word> will
>not show up in HTML."? And had problems displaying the content properly?
>If so then this is the problem I speak of.
>
>There are several ways of producing the content correctly:
>
>The most common one I believe that is used is that each and every bean is
>expected upon to format the content in the right manner.
>
>The problem with this is, unfortunately, is that it makes it difficult to
>write generic beans that produce content and are not aware of the context
>they are used in. This seems anti-thetical to the purpose of writing a
>"bean" which produces content and allows seperation of presentation and
>business logic.
>
>The second method I believe could be used would be to write a wrapper bean,
>or wrapper mechanism. This seems to be pretty klunky, since I think the
>only "real" way to do that would to be to make some sort of automatic
>script/code generator that looked at all the beans you intended to use, and
>created wrapper beans that would wrap all the get functions within those
>beans to encode the content in the proper manner. And then of course
>accessing the the get methods of the wrapper beans instead of the real bean
>is problematic too.
>
>The third mechanism I am aware of would be to put the transform code into
>the JSP page itself; I think most people should recognize what a painful and
>ugly solution that is.
>
>My proposal (which, through maybe no one's fault, though nevertheless has
>been ignored thusfar) is to make the JSP engine aware of the content-type of
>the output page (it already is!!) and to match that against the content-type
>of the bean producing the content.
>
>If they don't match, then a filter should be applied. There is already a
>mechanism to do this, and the JavaMail API already uses it effectively, it
>is the Java Activation Framework (or JAF).
>
>So please, tell me, what do you think of this problem, am I missing any
>other mechanism for solving it right now, and what do you think of this
>proposal? If you agree with me that this is a problem, how important does
>it seem to you that it be fixed?
>
>Thanks,
>
>Taylor Gautier
>Excite@Home Software Engineer
>
> ==========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
>FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
