On Mon, 10 Jun 2002, Jayson Falkner wrote:
> > In general, JSTL requires that users know less, making its use
> > easier. For instance, users of JSTL tags don't need to understand
> > the lifecycle considerations associated with a JDBC Connection,
> > Statement, or ResultSet;
>
> Do you think it is better to encourage use of JDBC and SQL by users
> that know less, or, is it better to encourage users to know more
> before dealing with it? Which way do you think the JSTL is encouraging
> users to go?
I think making functionality available to those who know less is what
abstraction is all about. As a point of comparison, Microsoft .NET claims
to let a number of languages interoperate. But all of these languages
exist at roughly the same level of abstraction, meaning that they're all
substantially the same: they're different syntaxes to address the same
problem. With the array of Java standards, my hope is that they cover
*different* levels in the abstraction hierarchy and are thus suitable for
different users.
> > I can certainly say, from my own experience and anecdotal evidence,
> > that prototyped pages (and small applications) can be faster to
> > develop in JSP than in JSP + Java.
>
> How much faster and is it because JSP auto-compiles?
You're asking for metrics I don't have and which, to be honest, I doubt
very many people have. (I'd say that applies even to those people whom
spend the majority of their time debating application-development
methodologies.) As an analogy, most people agree that DOM is "easier" to
develop with than SAX, but does anyone have metrics for "how much faster"?
You're holding JSTL to an extremely high (and perhaps impossible)
standard.
> > Sure - consider importing a header from another web application. Would
> > you really want Java code to do this, instead of a single <c:import>
> > action element?
>
> Why would you want to do this?
>
> If I had to, I would want Java code to do this for cache reasons. But,
> I can't think of a good reason why a external header would be needed.
Why replicate a common header across multiple web applications when
locating it in a single place allows you to change it once and have the
changes noticed immediately by multiple systems?
> The advantage of using Java is getting everything Java
> supports. Namely, you can easily write up some validation and error
> handling code in Java.
But we're talking about XML here; you don't typically want to write
validation logic in Java, instead relying on schema methodologies for the
integrity of the application. Separately, JSTL lets you catch errors and
logically pass them to Java code, if that's what you want to do.
> Both are unrelated to looping through some values but required when
> getting the information which is being looped through. Assuming the
> information is always correct is a stretch, especially if you are not
> responsible for generating the XML.
Not if it adheres to a schema.
> I meant the url action would be unfavorable versus a HTML-like link
> action authored individually on a per project basis. So if HTML was the
> only thing used it would be HTML, likewise for other formats.
But that sounds like wasted effort, which is worse than dealing with
<c:url>'s syntax.
> The point of asking was to see if encouraging use of the url action
> would be better then encouraging use of the API that powers it.
There are multiple APIs, however; using JSTL lets you ignore the details.
<c:url> both uses response.encodeURL() and normalizes relative URLs
against a context path.
> > Forwarding to a resource that's not in the web application (and is
> > thus beyond the reach of <jsp:forward>).
>
> Right, but why would you want to do this? The jsp:forward action is not
> something which is helpful either. The API it uses is very helpful, but
> making a tag out of the API doesn't seem to be of use. Do you think
> this type of tag should be encouraged for use with JSP?
It doesn't seem hard to come up with justifications of <jsp:forward>'s
utility. For instance, it can allow finer-grained error handling than JSP
errorPages:
<c:if test="${error1.occurred}">
<jsp:forward page="/error1Handler"/>
</c:if>
(where /error1Handler points, perhaps, to a servlet).
It can, more generally, link JSP pages and servlets flexibly; a JSP page
need not be the terminal component for every request.
--
Shawn Bayern
"JSTL in Action" http://www.jstlbook.com
(coming in July 2002 from Manning Publications)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
