Arthur Alexander wrote:
> Thanks for the response Craig,
>
> It seems you misunderstood my comments.
>
> You wrote:
>
> > "I guess the people that use servlets to
> > serve serialized Java objects (most commonly
> > to return one to an applet), or sound files,
> > or even dynamically generated images are
> > cheating, huh :-). The servlet can render
> > its output in any content type it wants, as
> > long as it says so via the setContentType()
> > header. "
>
> You make my point exactly, and we are in agreement.
> All of these content types, and the format of their
> transport and rendering - all of this conforms to
> the W3C HTML specification! Most common browsers
> see this and understand it as HTML content and will
> properly render it (or at least try, such as when
> a plug-in is required - which they will be happy
> to report you do not possess).
>
> They types of extension you are talking about are
> not beyond current HTML specs.
>
If you changed the term "W3C HTML specification" to "W3C
HTTP specification" in the above paragraph, I would agree with you.
Otherwise, I think you are still mixing up the terms. If not, could you
please point to *where* in the HTML specification you see references to
the various content types, or the "Content-Type" header itself? I sure
see it in the HTTP/1.0 spec (Section 10.5), as well as HTTP/1.1 (Section
14.17). The HTML/3.2 and HTML/4.0 specs only talk about what is
legal HTML -- not how you specify what is HTML and what is not.
>
> What I have not heard anyone really discuss, and
> the subject of this conversation thread (which you
> did allude to at the end of your note) is HOW will
> JSP help me create and manipulate other content
> streams and protocols, such as XML?
>
> Could you (or someone else in this forum who feels
> strongly about the subject or has a stake in it's
> outcome or progress) provide a simple example to
> encourage me and others to 'see the light' so to
> speak? It might spawn a listener to formulate a
> whole new pattern of XML development and
> distribution techniques that we can all benefit
> from.
>
I suggest that we look at a JSP source page a little differently -- it's
got some JSP tags (<USEBEAN>, <DISPLAY>, and so on) and some"not-JSP"
stuff. Today, most people (as you have pointed out) write the "not-JSP"
stuff in HTML, but why should they stop there? After all, the servlet
that gets generated simply stuffs all those "not-JSP" characters into
arrays, and dumps them out uninterpreted when it is executed. There's
no reason not to apply the concept of dynamic generation to other
content types -- in the case at hand, XML.
So what's the benefit? To me, it's the same benefit I get from JSP+HTML
-- being able to integrate dynamic content in a standards compliant
way. Just as a concrete example, let's assume I've got a JSP page that
displays a customer list. In my application, I create a bean that has a
"customers" property (indexed, returning individual customer beans) that
I stash in my user's session, and forward to the JSP page (I tend to use
the "Model 2" approach described in the JSP 0.92 specification).
So how do I actually display the list? Here's a snippet of a JSP page,
using HTML as the presentation language (HTML tags are lower case, JSP
tags are upper case for clarity):
<table border=0 width=600 cellspacing=5>
<tr>
<th>Customer Name</th>
<th>City</th>
<th>Phone Number</th>
</tr>
<LOOP PROPERTY="MyBean:customers" PROPERTYELEMENT="cust">
<tr>
<td align=left><b><DISPLAY PROPERTY="cust:name"></b></td>
<td><DISPLAY PROPERTY="cust:city"></b></td>
<td align=center><DISPLAY PROPERTY="cust:phone"></td>
</tr>
</LOOP>
</table>
Nice and neat ... business logic all encapsulated in beans, presentation
all encapsulated in HTML, and using the JSP mechanism to dynamically
integrate the two. And it works, no matter how many customers there are
(within reason, of course) because of the LOOP construct.
So, when looking at XML, why should I have to give up the ability to do
something like this? How, in pure XML or XML+XSL, do you accomplish
what the LOOP and DISPLAY constructs do for you? I would like to be
able to use this for XML as well! I want to do something on the order
of:
<customer-list>
<LOOP PROPERTY="MyBean:customers" PROPERTYELEMENT="cust">
<customer>
<customer-name><DISPLAY PROPERTY="cust:name"></customer-name>
<customer-city><DISPLAY PROPERTY="cust:city"></customer-city>
<customer-phone><DISPLAY
PROPERTY="cust:phone"></customer-phone>
</customer>
</LOOP>
</customer-list>
and let my XSL style sheet describe how this should be rendered on the
user's display.
Many people have thought about XML being a nice "next generation"
presentation language, once we get browsers that understand it. That is
definitely true, but it is not the only use. For example, XML is also
going to be heavily used to transport objects back and forth between
systems. Let's assume that, rather than displaying the customer list in
a browser, I was downloading those customers to my trading partner's
database as a series of XML objects. Sure, I can write a Java (or
whatever) program to create the data stream, but why shouldn't I be able
to do the same thing with a JSP "page" that is really a filter script
that lets me customize which data elements I want to include, and how
they are organized, without having to write any programs? Or, I can
just use the same snippet shown above, but with a different stylesheet
to control the layout ...
The same principle applies even if all I want is your traditional
comma-separated-values ASCII dump ... the "not-JSP" part of my script
can be anything I want. Not just HTML.
There are several initiatives around that are aiming at adding this sort
of dynamic behavior to XML+XSL. It seems to me that JSP is a pretty
obvious choice to be one of these alternatives, once the low level
syntax issues get worked out.
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
