commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [jelly] <j:switch> and <j:break>
Date Tue, 10 Dec 2002 13:12:59 GMT
Another possibility that occurs to me is to require each <case> to have
some <break> child, even if it is <break test="false/>, for some interim
period.  That would force any <switch> users to update and would be
forward compatiable with eventually making the "false breaks" optional.

(I assume I can walk down the tree effectively with some combination of
getBody/getScriptList/getTag and casting?)

On Mon, 9 Dec 2002, Rodney Waldhoff wrote:

> 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>
>
>


--
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