tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vernon Wu <vern...@gatewaytech.com>
Subject Re: RE: What is the rationale: (was RE: is there a better way to do t his without JSP Script var)
Date Mon, 05 Aug 2002 09:37:44 GMT

Those are the reasons in theme, or what JSTL mean to be. In reality, the current version of
JSTL has achieved the 
most of the goal, thank for JSTL team for their a lot of hard work. 

There are few problem thought. After employing the message tag of fmt in JSTL, I, however,
experience a tumble 
perfromance during the JSP translation phase on a container TC4.0.4. And more serious one,
a large number, say more 
than a hundred,  of the tag appearence on one page can crash the server.

Even though, I still think JSTL is a wonderfull development tool.

 
8/5/2002 8:56:04 AM, "Martin Cooper" <martin.cooper@tumbleweed.com> wrote:

>My key reasons are:
>
>* Readability. For most people, reading a page written using a single syntax
>is easier than reading one which uses multiple intermixed syntaxes, with
>what are effectively escape sequences to switch between them.
>
>* Maintainability. In my experience, it is much simpler for people to
>enhance or fix pages written using only tag syntax than pages which intermix
>both tags and scriptlets. People tend to end up with mismatched or misplaced
>scriptlet brackets more often than you might think.
>
>* Performance. There are a couple of factors here. First, using JSTL allows
>me to take advantage of my container's built-in optimised support for these
>tags. Second, it allows the page compiler to be smarter about breaking up
>the page, freeing me from the woes of the "Illegal target of jump or branch"
>exception during page compilation. Finally, as Shawn mentioned, future
>versions of JSP will allow further performance gains as a result of using
>JSTL and its EL.
>
>* Flexibility. If I use no scriplets or scripting expressions, and I use
>XHTML syntax instead of the looser HTML, then I can manipulate and transform
>my pages using XSL. I could certainly generate pages that use scriptlets
>using XSL, but then I wouldn't be able to parse them back in and further
>manipulate them.
>
>* Fewer surprises. In my experience, scriptlets have a greater potential for
>unexpected exceptions arising during execution of a page. I don't like
>surprises. ;-)
>
>
>FWIW, the reason Struts doesn't have if/else tags is because we didn't want
>to grow this side of the Struts taglibs when we knew that JSTL would take
>care of these kinds of issues, with an expression language to boot. Over
>time, Struts developers will be encouraged to migrate to JSTL tags where
>appropriate, while the Struts taglibs focus more narrowly on Struts-specific
>functionality.
>
>--
>Martin Cooper
>
>
>> -----Original Message-----
>> From: Dennis Doubleday [mailto:dennis@righthandmanager.com]
>> Sent: Monday, August 05, 2002 7:21 AM
>> To: 'Tag Libraries Users List'
>> Subject: What is the rationale: (was RE: is there a better way to do
>> this without JSP Script var)
>> 
>> 
>> 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.
>> 
>> > > > > > > > > > > > Is there a better way to do
this without 
>> > JSP Script 
>> > > > > > > > > > > > var
>> > > > > > > > > > > >
>> > > > > > > > > > > > <c:forEach var="rs" items="${question.rows}">
>> > > > > > > > > > > >   <c:set var="qType" 
>> > value="${rs.QUESTION_TYPE}" />
>> > > > > > > > > > > >   <% String sqType =
>> > > > > > pageContext.getAttribute("qType").toString();
>> > > > > > > > > > %><br>
>> > > > > > > > > > > >
>> > > > > > > > > > > >   <%if (sqType.equals("1"))
{ %>
>> > > > > > > > > > > >      <c:set var="controlType"
value="radio" />
>> > > > > > > > > > > >   <%} else if (sqType.equals("2"))
{%>
>> > > > > > > > > > > >      <c:set var="controlType"

>> value="checkbox" />
>> > > > > > > > > > > >   <%} else if (sqType.equals("2"))
{%>
>> > > > > > > > > > > >      <c:set var="controlType"
value="select" />
>> > > > > > > > > > > >      <c:out value=" <select>
"/>
>> > > > > > > > > > > >   <%} %>
>> > > > > > > > > > > >
>> > > > > > > > > > > > </c:forEach>
>> > > > > > > > > > >
>> > > > > > > > > > > The following should work:
>> > > > > > > > > > >
>> > > > > > > > > > >  <c:forEach var="Rs" items="${questions.rows}">
>> > > > > > > > > > >    <c:set var="qType" 
>> value="${rs.question_type}" />
>> > > > > > > > > > >    <c:choose>
>> > > > > > > > > > >      <c:when test="${qType ==
1}">
>> > > > > > > > > > >        ...
>> > > > > > > > > > >
>> > > > > > > > > > > and so forth.
>> 
>> 
>> --
>> To unsubscribe, e-mail:   
>> <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <mailto:taglibs-user-help@jakarta.apache.org>
>> 
>> 
>
>
>--
>To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>
>
>




--
To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>


Mime
View raw message