Robert,
I would think that the primary advantage of JSP's over the method you have
developed in house at Qwest would be that JSP has a standardized approach
for encoding tags. I have worked with several servlet engines such as yours
but my company is going to be switching to JSPs for several good reasons.
First, there will be many third party JSP development environments and
numerous shared tag libraries. If you think about the work you must have
done at Qwest to build a proprietary tag definition language, with it's own
nuances and limitations- why not switch to JSP technology? Over time your
ROI will be much better going with an industry standard rather than having
to continually develop your own servlets and extensions to your own
language. Right now other tag definition languages have 3rd party tools,
such as allaire's cold fusion studio (an offshoot of homesite), for doing
page based design rapidly and reliably. I am sure similiar technologies
will arrive soon for JSP's, but think of the time it would take to write an
editor for a proprietary tag language of your own creation. Granted, you
might prefer notepad or vi, but I think you would agree that some people can
learn and work much faster with a good integrated editor. This should let
engineers write the real code and let html/ia people write the templates.
Secondly, JSP's allow a full range of flexability with regard to data
separation. In most instances I can think of with JSP's I have written to
date, I have tried to encapsulate all the Java code into Beans, much as you
have with your servlet system. However, there are occassions where being
able to encode programatic logic into the template will significantly
decrease the amount of development time needed to take an application live.
(It is much faster to debug and try then having to recompile a servlet each
time). Future code reusability is not always the most efficient way to get
a project done, and in those cases where something needs to be done very
quickly and won't be reused, java code in templates can work very well.
To summarize, I think that right now JSP is just in its infancy, but if you
look at the direction it is going, I think you will agree that it could be a
major standard for creating dynamic web content in the next few years. By
being an accepted standard, there will be many advantages to it that a
properitary system (be it servlet, ASP, php3, or CF) will have a difficult
time matching. 3rd party support will increase the tools at your disposal.
There are already JSP servers that come with built in WAP support, so I
think this would be a good direction for a tele-communications company to
go.
Joshua Lannin
_|_|_| _|_|_| _|_|_|
_| _| _|
_| _|_| _| _|_|
_| _| _| _|
_|_|_|lobal _|_|_|ommerce _|_|_|ystems
Joshua D. Lannin 4840 Pearl East Circle
Software Engineer Suite 301-W
[EMAIL PROTECTED] Boulder, CO, 80301
Phone 303 583.2088 Fax 303 583.5100
PGP key http://infonectar.com/JL.asc
------------------------------------------
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Husted, Robert
> Sent: Monday, November 08, 1999 12:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: In what ways does JSP score over Servlets ?
>
>
> At Qwest we are using templates... HTML files with
> placeholders for data
> ${MY_PLACEHOLDER}. We store the template in memory and then
> insert the data
> into the template and display it to the user. The advantage is that our
> HTML code doesn't appear in the Servlet. In addition, our Java
> code doesn't
> appear in the template... so we've cleanly separated the Java
> code from the
> HTML.
>
> What is the advantage of using a JSP over a Servlet that uses
> templates?
> As far as I can tell, there is no advantage... we've actually
> done a better
> job of separating code and presentation logic using templates.
> Can someone
> give me a concrete example of when JSPs might be better than a
> Servlet that
> employs templates?
>
> Thanks,
>
> - Robert =)
>
>
>
> -----Original Message-----
> From: Steve Wamsley [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 06, 1999 12:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: In what ways does JSP score over Servlets ?
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 1. JSP's are really servlets when comes right down to it.
> 2. Do you really want to create a large-scale browser-based
> application composing all the HTML in out.println() calls?
>
> Steve Wamsley
> http://home.earthlink.net/~sswamsley
> <http://home.earthlink.net/~sswamsley>
> - ----- Original Message
> -----
> From: Swapnil Gupta
> To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> Sent: Saturday, November 06, 1999 12:33 AM
> Subject: In what ways does JSP score over Servlets ?
>
>
> Hello Frenz,
> I have gone through quite a bit of literature and
> information on JSPs and Servlets.
> I do not find very convincing as to how JSPs score any significant
> advantage over Servlets. I am aware and understand the more common
> points where JSP does well like easy maintanence and development and
> also some built in tag based support for easy interaction with EJB.
> Besides these are there any significant gains in going for
> JSP/Servlets rather than Servlets.
>
> Thanks,
>
> Swapnil.
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.1 for non-commercial use < http://www.pgp.com
> <http://www.pgp.com> >
>
> iQA/AwUBOCSHS5aPN/z+dlkyEQJy+wCgixBL1l4Z29AqycOql58X/XgHYVcAmweG
> UZgBH1r0H8xBRNTLL3U8LhN2
> =qJdz
> -----END PGP SIGNATURE-----
>
> ==================================================================
> =========
> 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
