> -----Original Message-----
> From: Paul Philion [SMTP:[EMAIL PROTECTED]]
> Andy Bailey wrote:
> > Just because JSP has some of its roots in ASP does not mean that JSP is
> a
> > bad thing. It means the ASP designers can leverage their familiarity
> > with the structure of ASP files over to JSP. JSP 1.0 certainly is a big
> > improvement on ASP and ASP has, at its heart, a terribly flawed language
> > which JSP's do not.
> >
> > JSP was an attempt to provide the power of servlets to web developers in
> an
> > already familiar format. Eminently sensible as it means no one who is
> > familiar with ASP and Java need learn something new.
>
> I should have ordered my points differently: This point becomes more
> powerful (for me at least) after making the point that the basic ASP
> principle -- embedding code in an HTML page -- makes (IMHO) for a poor
> architecture. In fact, I think it encourages it. Assuming that this is a
> valid opinion (obviously I do) it follows that I think that people at Sun
> made a *marketing* decision to push JSP. Yes, JSP if far superior to ASP;
> but it still allows the mangling of HTML with code.
>
ASP is the 700 pound gorilla of web application development and I
think it's good that the JSP API competes directly with ASP. When a tool
vendor has to decide whether they're going to develop a tool compatible with
ASP or the Sun/Java techonology they have to be comfortable going with
Sun/Java. A competing web development technology must obviously take on ASP
in the marketplace or it will whither, and that means having a feature list
that that web developers will compare with ASP. It's too bad that other
vendors let Microsoft get a head-start in this market. Hey, MS was actually
forward-thinking and innovative and they gotta deal with it now.
> > > 2) The whole point of a template system is to allow the clear
> seperation
> > of business logic and presentation. JSP allows to two to be coupled
> tightly.
> > In fact, I would say (from the lazy programmer point-of-view) the JSP
> > encourages the tight coupling.
> >
> > Any system that does not enforce loosely coupled design and
> implementationn
> > will have this problem.
> > This is a problem to do with the designer/programmer and not the system.
> >
> > JSP's do make it very easy to decouple business logic and presentation,
> as
> > do ASP's when used correctly.
> >
> > JSP's have JavaBeans and ASP's can use COM, precisely as was intended.
>
> Completely correct. The exact same argument can be applied to pointers,
> memory management, multiple inheritance and many other aspects of modern
> software development. The interesting point is that Java *forces*
> developers to do things differently by removing these issues from the
> language/environment.
>
> The important point is "when used correctly"... I have found that many
> technologies are not used "correctly", either through ignorance, laziness
> or incompetence. I have seen plenty of really bad Java code, and loads of
> bad C++. I'm forced to do the "wrong thing", far more often than I like,
> simply due to real world resource constraints.
Even the most well designed products can be used incorrectly.
There's nothing to stop me from drinking a bottle of tequila and then
driving my Ferrari (hey, it's the Internet, I can be as cool as I wanna be!)
into a crowd of people. There's no such thing as fool-proof technology.
However, there are products that can be inflexible, restrictive, and hard to
use. That the JSP API is reusable in a variety of ways is a "good thing".
Many times I've had a similiar argument with developers that believe
in developing "bullet-proof" APIs. A bullet-proof API is an API that will
never do "bad things" even when given bad input. For instance, a
bulletproof version of the C memcpy function would be a version of memcpy
that doesn't do bad things when given a null destination pointer. My
argument is that you have to know how the API is to be used and then use it
correctly. An API must be well documented and users must have read the
documentation. If you're using an API incorrectly because you haven't done
your homework then you've already lost the game, bullet-proofing only make
an API bloated, slow, and ultimately less reusable.
ted stockwell
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
