You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@apache.org> on 2002/12/10 03:22:06 UTC
[jelly] and
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] and
Posted by James Strachan <ja...@yahoo.co.uk>.
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" <rw...@apache.org>
To: <co...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] and
Posted by Rodney Waldhoff <rw...@apache.org>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>