Arthur Alexander wrote:
> My apologies to the group
> ( thanks Craig and Costin for pointing it out).
>
> I did indeed mean HTTP specification, yet I think
> that my meaning was the same. HTML and HTTP are
> so tightly bound that the specifications are, for
> the most part, considered integral.
>
> What mechanics are there for viewing HTML that
> does not utilize HTTP? Very few I would bet.
> How many clients utilize HTTP and do not
> expect content that conforms to the HTML spec,
> of course with other embed's.? Again I think
> the honest answer is very few indeed.
>
On my PC, I have my browser set up to load my default home page from my file
system, so that it works even when I'm not connected to the Internet. The URL
is:
file:///C|/webhome/index.html
which is not loaded via the HTTP protocol. This approach is commonly
employed, for example, on documentation that is supplied on a CD-ROM in HTML
format, so that the reader doesn't have to mess with a web server.
Likewise, when you browse an FTP server's file directory through your browser,
and then click the hyperlink for a file that has a ".html" extension, your
effective URL is
ftp://ftp.yourcompany.com/some/directory/somefile.html
which, again, has nothing to do with the HTTP protocol -- your browser fetches
the file via FTP instead. In either case, if the page content of the files is
identical (and any referenced images are also present in the right places),
what I see in my browser is identical -- regardless of how the bytes of the
page got delivered. At the risk of belaboring the obvious:
* HTML is a content type that can be delivered by lots
of protocols. It is often delivered by HTTP,
but requires no changes to be delivered by any
other protocol.
* HTTP is a protocol that can deliver lots of content types.
It is used on web sites to deliver HTML, images, sound
files, plugins, serialized Java objects, installable
applications in ZIP files, .......
Tying the two concepts together, even if it is a very common usage today, is
really limiting your thinking. But enough of this -- the relevant comment for
the JSP-INTEREST list is on your next paragraph.
>
> Sounds to me like you have all of the mechanics
> you need for your dynamic XML construction/parsing
> in the Servlet class mechanics Craig. The only
> reason for looking for a script based extension (JSP?)
> that I seem to hear is providing another, possibly
> easier to access mechanism that a Servlet.
>
As a Java developer, I'm quite comfortable with using servlets to render
dynamic content. I have written my share of apps using this approach, before
I understood the power of JSP myself. However, there are some scenarios that
make the option to use a scripting environment like JSP quite valuable:
* When creating the page in the first place, I want
to use HTML authoring tools (and will be able to
once they start supporting JSP tags :-). I can't
easily do this when I'm rendering HTML in Java.
(Naturally, the same goes for XML content.)
* When I want to change the look and feel of the
rendered pages later, it is much easier to do this
in JSP pages rather than in the Java source code
of the original servlet.
* When I want a professional page designer to build
the pages because he or she is *much* better at the
presentation stuff than I am, I want to be able to
either teach them how LOOP and DISPLAY tags
work, or go in after the fact and add them to the
pages they have created.
* As a side benefit to me as a developer, the discipline
of separating business logic and presentation leads
to cleaner, more robust, more reusable, and more
scalable application designs than cases where the
two things are intermixed.
Many of these sorts of benefits accrue from pretty much any of the scripting
and page templating technologies that are out there. The additional advantage
of JSP is that the tags used to embed it will be standardized across server
platforms, so I never get stuck with a proprietary script or template language
that only runs in one particular environment. I will be able to run JSP based
applications on anything from an embedded system to a huge distributed
application server environment with no changes to my pages, and that is pretty
compelling, for the same reasons that people like Java's portability. I'd
rather go build something new and interesting, rather than having to go back
and port my old stuff to a new environment simply to keep up with growth in
demand.
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".
