commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [jelly] <j:switch> and <j:break>
Date Tue, 10 Dec 2002 16:21:24 GMT
I do like the simplicity of <switch> and <case> without the need for
explicit <break> tags - I think there's something quite nice about the
contents of the <case> tag representing a block. How useful do you think the
falls though behaviour is? I'm just wondering if its worth all the trouble.
Maybe we could just have a simple syntax for handling common code for
multiple values.

e.g.

<switch on="${foo}">
<case>
    <value is="a"/>
    <value is="b"/>
    <value is="c"/>
    <!-- do something -->
</case>
<case value="d">
    <!-- do something else -->
</case>


Another thought could be to wrap up common code as a script and invoke it as
a tag which could be simpler and less typing and give a much more powerful
ability to implement 'falls through' allowing more complex pre and post
processing hooks. e.g.

<define:script var="foo">
    <!-- do something common -->
</define:script>

<j:switch on="${foo}">
<j:case value="a">
    <define:invoke script="${foo}">
</j:case>
<j:case value="b">
    <!-- something special before foo -->
    <define:invoke script="${foo}">
</j:case>
<j:case value="c">
    <define:invoke script="${foo}">
    <!-- something special after foo -->
</j:case>
<j:case value="d">
    <!-- something special before foo -->
    <define:invoke script="${foo}">
    <!-- something special after foo -->
</j:case>

James
-------
http://radio.weblogs.com/0112098/
----- Original Message -----
From: "Rodney Waldhoff" <rwaldhoff@apache.org>
To: <commons-dev@jakarta.apache.org>
Sent: Tuesday, December 10, 2002 2:22 AM
Subject: [jelly] <j:switch> and <j:break>


> I originally implemented the <case> tag with a fallsThru parameter, so
> that the following:
>
> <j:set var="foo" value="1"/>
> <j:switch on="${foo}">
>  <j:case value="1" fallsThru="true">
>    <!-- A -->
>  </j:case>
>  <j:case value="2" fallsThru="false">
>    <!-- B -->
>  </j:case>
>  <j:case value="3" fallsThru="false">
>    <!-- C -->
>  </j:case>
> </j:switch>
>
> would evaluate the both the block marked <!-- A --> and the block marked
> <!-- B -->, but not <!-- C -->.
>
> For better or worse (I'm starting to think worse) I let "false" be the
> default for fallsThru, thinking that's the common case and less verbose
> than the alternative (and boolean defaulting to false felt right), so the
> above could be written simply as:
>
> <j:set var="foo" value="1"/>
> <j:switch on="${foo}">
>  <j:case value="1" fallsThru="true">
>    <!-- A -->
>  </j:case>
>  <j:case value="2">
>    <!-- B -->
>  </j:case>
>  <j:case value="3">
>    <!-- C -->
>  </j:case>
> </j:switch>
>
> Since that time, the <break> tag has been added and is supported by
> <forEach> and <while>.  Since having <break> but not supporting it
in
> <switch> is counter-intuitive, I'd like to have <switch>/<case> support
> <break>, like this:
>
> <j:set var="foo" value="1"/>
> <j:switch on="${foo}">
>  <j:case value="1">
>    <!-- A -->
>  </j:case>
>  <j:case value="2">
>    <!-- B -->
>    <j:break/>
>  </j:case>
>  <j:case value="3">
>    <!-- C -->
>    <j:break/>
>  </j:case>
> </j:switch>
>
> But of course that means the default for fallsThru (assuming the attribute
> exists at all any more) must change to "true", as in the general Java
> case.
>
> <switch>/<case>/<default> support is relatively new, so I'm not sure
how
> widely it is used (I use it a lot, but I can update those easily), but I'm
> looking for ways to make this switch while adhering to the principle of
> least suprise.
>
> The options that strike me are:
>
> 1) We could simply drop support for @fallsThru and instead support break,
> but that may change the behavior of some scripts without warning. This is
> actually fine with me if we don't think it is widely used currently.
>
> 2) We could make case@fallsThru a required parameter (with no implicit
> default), issuing a strong warning or even an exception when it is not
> set.  We would then have several options for slowly deprecating or slowly
> changing the default, for example (in the remove-support case) by issuing
> a warning whenever @fallsThru is false, then throwing an exception
> whenever @fallsThru is false, and finally issuing a warning whenever
> fallsThru is set at all.
>
> 3) As a helpful but not complete solution, as an extension of (1) we could
> issue a warning whenever fallsThru is set, which may help notify users who
> haven't updated their scripts, but it won't help if they never actually
> use a fall-thru case.
>
> There are fairly obvious and more or less complicated variations as well,
> like issuing a log message the first time <switch> is used to call
> attention to the change, or changing the default depending upon whether
> <break> is ever used, etc.
>
> I'm not especially happy with any of these, but on the bright side as far
> as I know we've never even done an alpha or milestone release of jelly
> including these tags, which I think makes me lean toward (1)/(3).  Option
> 2 is more fool-proof, since unless you skip a relase or two there's no way
> you won't know about the change, but it would require users to change
> scripts at least twice--once to make fallsThru required, and another to
> remove it later (and all the scripts written in the interim will be a
> little more verbose).
>
> Any preferences? Does anyone even care? Is there a solution I'm not
> seeing?
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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


Mime
View raw message