tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From otisg <ot...@ureach.com>
Subject Re: RE: missing if/else syntax
Date Thu, 08 May 2003 20:59:55 GMT
Shawn, you are saying 'we', so it looks you participated in
decision making, or were at least close to it.
I'm just curious, why was c:choose chosen, insteaf of (a more
'natural') c:switch?

Lot's of programming languages use the switch keyword.  I don't
use any PL that uses choose keyword.  Does XSLT use choose?  If
so, why did they decide on choose, any idea?

Thanks,
Otis



________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag


---- On Thu, 8 May 2003, Shawn Bayern (bayern@essentially.net)
wrote:

> On Thu, 8 May 2003, Henri Yandell wrote:
> 
> > Nope:
> > 
> >  <c:either test="${ifTag.Existed}">
> >    <c:do>
> >      <c:either test="${another.Test}">
> >        <c:do>..</c:do>
> >        <c:or>..</c:or>
> >      </c:either>
> >    </c:do>
> >    <c:or>...</c:or>
> >  </c:either>
> > 
> > Which is just a <c:choose> switch statement anyway.
> 
> Heh.  This discussion is rapidly coming to resemble the expert
group's
> deliberations.  We considered many different variants -- those
listed here
> and even other, stranger beasts(*) -- and decided on
choose/when/otherwise
> for a few reasons, some of which have already been pointed
out:
> 
>  1. A parent <choose> tag plays by XML's rules, is
straightforward to
>     implement, and is in fact what XSLT (facing the same
problem) chose.
> 
>  2. It supports multiple branches more cleanly than if/else
>     constructs do when represented as XML tags.
> 
>  3. It drew a clean line between complex (multi-way)
conditions and simple
>     conditions (<c:if>) and allows them to be mixed
orthogonally and with
>     little confusion.  Simple conditionals with <c:if> NEVER
have an
>     effect on anything outside their immediate tag, whereas
<c:when>
>     and <c:otherwise> alter the flow within their parent tag.
> 
> Having said all this, decisions like this are necessarily made
with large
> doses of subjective intuition and judgment; it's possible and
even likely
> that different constructs will appeal for legitimate reasons
to different
> designers.  The EG picked the tags that generated the most
consensus and
> provided for the most function with the fewest primitives.
> 
> -- 
> Shawn Bayern
> "JSTL in Action"   http://www.manning.com/bayern
> 
> 
> (*) I believe I once floated the idea for a single tag called
<c:cond>
> that adapted to its environment depending on neighboring
<c:cond> tags to
> become a 2-way or multi-way condition as necessary.  Another
crazy idea
> involved open-ended mutual exclusivity achieved at runtime
with a tag
> called something like <c:exclusive label="...">; this tags
would prevent
> other <c:exclusive> tags with the same label -- and their
bodies -- from
> executing
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
taglibs-user-help@jakarta.apache.org
> 
> 
> 


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


Mime
View raw message