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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
