tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter lin <>
Subject Re: What is the rationale: (was RE: is there a better way to do this without JSP Script var)
Date Mon, 05 Aug 2002 14:34:09 GMT

Having worked in a variety of environments, JSTL helps reduce the
learning curve for designers who don't program or HTML coders who don't
want to learn an OO language.  By far using scriptlet is faster for an
experienced programmer, but for large projects the chances of everyone
being experienced in all necessary skills is rare.

most hardcore graphic designers that I know don't want to deal with
programming. the most they want to do is some HTML and that's it. Some
friends are hardcore on flash and don't have a problem with programming,
but those are rare. obviously what ever the choice is there's a learning
curve. trying to explain the concept of scoping to someone who hates to
program isn't always easy. Atleast from my experience it's easier to
give them tags, which looks familiar to them and doesn't appear as


Dennis Doubleday wrote:
> This is not a troll, this is an honest question.
> Is there a reason for an experienced Java programmer to prefer JSTL
> expression language over just using Java scripting?
> Perhaps the EL (or Struts logic tags, which I am currently using) are
> simpler for the page designer who doesn't know Java--I can't speak to
> that. But my experience has been that I am far more likely to make a
> mistake using Struts logic tags than if had just scripted the
> conditionals, because I know Java so well. And, although this apparently
> would not be a problem with JSTL, with Struts logic you end up putting
> redundant tests in because of the lack of an "else" capability, e.g.
> <logic:equal {some test condition}>
>   ...
> </logic:equal>
> <logic:notEqual {repeat the same condition, a redundancy that increases
> the chance for error and is a maintenance issue}>
>   ...
> </logic:notEqual>
> But in both cases, we seem to be pretending that we are moving scripting
> out of the presentation layer, but in reality are simply expressing the
> scripting in a different language, whose own particular vocabulary must
> now be mastered in addition to Java.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message