Thanks again for the comments Shawn,

Shawn Bayern wrote:
> 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 see, but it would be helpful if you could narrow this down to 
specifically relating to the JSTL XML and SQL tags. Those are what I'm 
most interested in. Would it be correct to interpret this as you do 
think the JSTL encourages users to know less, but that isn't a bad 
thing; Lowering the level of knowledge required is something abstraction 
is good for, and, it means different types of developers can more easily 
use the same functionality?

Would you conisder yourself someone who benefits from the JSTL XML and 
SQL tags? why/why not?

>  > 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.

Specific numbers like a benchmark are not important, I was referring 
more to development time as you perceive it. When developing with JSP 
and XML and/or SQL, and you have the choice of using either the JSTL or 
a design pattern you well understand (perhaps MVC or embedding 
scriptlets) which do you choose and why?

>  > Why would you want to do this?
>  > 
> 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?

As in multiple servers running the same web app? If this was the case 
and there was part of a header which would change often why not make it 
dynamic and centralize it in the main datasource (likely in a db)? For 
big changes to the web app it would make sense to have a scheme which 
redeploys the entire web app as needed, perhaps by hot-deployment so the 
servers do not need to be shut down.

A single external import for something like a header does not seem to be 
very helpful. I do not wish to debate pointlessly about how things could 
get done. There are many ways, which I realize, however personal votes 
are really what I want. Have you ever had to personally used the import 
action for a good purpose (not examples of course ;)? If so what was it 
and did it do a good job?

> 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.

I think I see what you are saying, in your opinion the XML tags are 
really designed for best use when relying on previous proper use of XML 
schemas?

>  > information is always correct is a stretch, especially if you are not
>  > responsible for generating the XML.
> 
> Not if it adheres to a schema.

Right, same as above. The case is when your schema is not being enforced 
by Java. So someone using the XML tags would likely understand XML well 
and the schemas related to it, or count on someone else for these skills.

>  > 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.

Okay, so you are saying it is more effort to shift this to building it 
as needed on a per-project basis, the better approach would be to use 
the slightly awkward url tag sytanx?

>  > 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.

Again I am most interested in your personal opinion. There are many ways 
in which JSP can be used. Do you use the the jsp:forward action and/or 
the JSTL version of it? why not/why and what are the most common uses?

Cheers,

Jayson Falkner
[EMAIL PROTECTED]




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to