You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Martin Cooper <ma...@tumbleweed.com> on 2001/05/23 09:12:59 UTC
Logic tags and string properties
It seems that it is not possible to use the logic tags to test "is this
property either null or an empty string?". Using <logic:present>, I can
determine that some value is present, but as far as I can tell, there is no
way to test for an empty string. Specifying value="" for tags such as
notEqual seems to result in a complaint that a required attribute has not
been specified. (Is this correct, or is this a bug in Resin, the container
I'm using?)
So, I had a couple of ideas for solving this, and I'd like to hear what
people think.
1) Modify the present and notPresent tags such that the empty string is
equivalent to null for the purposes of this test, if in fact the specified
property is a String. This might break things, though - I'm not sure.
2) Define two new logic tags - perhaps empty and notEmpty - which define
emptiness as a property being either null or the empty string. Unlike
present and notPresent, these tags would only work with the name and
property attributes (i.e. not cookie, parameter, etc), since the others
don't really make sense distinct from present and notPresent.
The second option appeals to me more, because it seems somewhat cleaner than
muddying the definition of presence to include type-specific values.
Comments, anyone?
--
Martin Cooper
Re: Logic tags and string properties
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Martin,
+1 to the second case
Wednesday, May 23, 2001, 11:12:59 AM, you wrote:
MC> It seems that it is not possible to use the logic tags to test "is this
MC> property either null or an empty string?". Using <logic:present>, I can
MC> determine that some value is present, but as far as I can tell, there is no
MC> way to test for an empty string. Specifying value="" for tags such as
MC> notEqual seems to result in a complaint that a required attribute has not
MC> been specified. (Is this correct, or is this a bug in Resin, the container
MC> I'm using?)
MC> So, I had a couple of ideas for solving this, and I'd like to hear what
MC> people think.
MC> 1) Modify the present and notPresent tags such that the empty string is
MC> equivalent to null for the purposes of this test, if in fact the specified
MC> property is a String. This might break things, though - I'm not sure.
MC> 2) Define two new logic tags - perhaps empty and notEmpty - which define
MC> emptiness as a property being either null or the empty string. Unlike
MC> present and notPresent, these tags would only work with the name and
MC> property attributes (i.e. not cookie, parameter, etc), since the others
MC> don't really make sense distinct from present and notPresent.
MC> The second option appeals to me more, because it seems somewhat cleaner than
MC> muddying the definition of presence to include type-specific values.
MC> Comments, anyone?
--
Best regards,
Oleg mailto:gonza@penza.net
Re: Logic tags and string properties
Posted by Jonathan Asbell <ja...@i-2000.com>.
why dont you just change it to "isEmpty" or "emptyString" which everyone
knows already? =)
----- Original Message -----
From: "Martin Cooper" <ma...@tumbleweed.com>
To: <st...@jakarta.apache.org>
Sent: Monday, June 25, 2001 1:19 AM
Subject: Re: Logic tags and string properties
> Picking up on an old thread here (because I'd like to go ahead and fix the
> problem :-) ).
>
> If we add an 'empty' attribute to <logic:present> and <logic:notPresent>,
> what should the allowed values be?
>
> One option which occurs to me is that "empty='true'" would mean that the
> condition is true if the property is an empty string, while
"empty='false'"
> would mean that the condition is false if the property is an empty string.
> To preserve the existing semantics of these tags when the attribute is not
> specified, 'empty' would default to 'true' for <logic:present> and 'false'
> for <logic:notPresent>.
>
> Is this what you had in mind?
>
> --
> Martin Cooper
>
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <cr...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, May 23, 2001 9:29 AM
> Subject: Re: Logic tags and string properties
>
>
> >
> >
> > On Wed, 23 May 2001, Martin Cooper wrote:
> >
> > > It seems that it is not possible to use the logic tags to test "is
this
> > > property either null or an empty string?". Using <logic:present>, I
can
> > > determine that some value is present, but as far as I can tell, there
is
> no
> > > way to test for an empty string. Specifying value="" for tags such as
> > > notEqual seems to result in a complaint that a required attribute has
> not
> > > been specified. (Is this correct, or is this a bug in Resin, the
> container
> > > I'm using?)
> > >
> >
> > This is ultimately due to a restriction on the way that
> >
> > <jsp:setProperty name="beanname" property="*"/>
> >
> > works, which I copied in the BeanUtils and PropertyUtils classes. As
the
> > properties are being copied, if the input value is a zero length string,
> > it is *not* copied.
> >
> > Changing this behavior now would be very likely to break existing code,
so
> > I think we need to deal with it. But, your question is more general in
> > scope because the input beans could come from the application as well.
> >
> > > So, I had a couple of ideas for solving this, and I'd like to hear
what
> > > people think.
> > >
> > > 1) Modify the present and notPresent tags such that the empty string
is
> > > equivalent to null for the purposes of this test, if in fact the
> specified
> > > property is a String. This might break things, though - I'm not sure.
> > >
> > > 2) Define two new logic tags - perhaps empty and notEmpty - which
define
> > > emptiness as a property being either null or the empty string. Unlike
> > > present and notPresent, these tags would only work with the name and
> > > property attributes (i.e. not cookie, parameter, etc), since the
others
> > > don't really make sense distinct from present and notPresent.
> > >
> > > The second option appeals to me more, because it seems somewhat
cleaner
> than
> > > muddying the definition of presence to include type-specific values.
> > >
> >
> > A third option would be to add an "empty" attribute to the
<logic:present>
> > and <logic:notPresent> tags, which tells them how to treat empty
> > strings. The default, of course, would be the current behavior.
> >
> >
> > > Comments, anyone?
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > >
> > >
> >
> > Craig
> >
> >
>
>
Re: Logic tags and string properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 24 Jun 2001, Martin Cooper wrote:
> Picking up on an old thread here (because I'd like to go ahead and fix the
> problem :-) ).
>
> If we add an 'empty' attribute to <logic:present> and <logic:notPresent>,
> what should the allowed values be?
>
> One option which occurs to me is that "empty='true'" would mean that the
> condition is true if the property is an empty string, while "empty='false'"
> would mean that the condition is false if the property is an empty string.
> To preserve the existing semantics of these tags when the attribute is not
> specified, 'empty' would default to 'true' for <logic:present> and 'false'
> for <logic:notPresent>.
>
Thinking about it some more, I'd prefer if you did two new tags
<logic:empty> and <logic:notEmpty> instead. The reasons for this:
- The <logic:present> and <logic:notPresent> tags deal with
all kinds of properties, but the concept of "emptiness" is
unique to Strings. What are you going to do with a Date or
an int when asked if it is empty?
- You can explicitly define <logic:empty> to test for null or ""
and it should be easily understood.
> Is this what you had in mind?
>
> --
> Martin Cooper
>
Craig
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <cr...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, May 23, 2001 9:29 AM
> Subject: Re: Logic tags and string properties
>
>
> >
> >
> > On Wed, 23 May 2001, Martin Cooper wrote:
> >
> > > It seems that it is not possible to use the logic tags to test "is this
> > > property either null or an empty string?". Using <logic:present>, I can
> > > determine that some value is present, but as far as I can tell, there is
> no
> > > way to test for an empty string. Specifying value="" for tags such as
> > > notEqual seems to result in a complaint that a required attribute has
> not
> > > been specified. (Is this correct, or is this a bug in Resin, the
> container
> > > I'm using?)
> > >
> >
> > This is ultimately due to a restriction on the way that
> >
> > <jsp:setProperty name="beanname" property="*"/>
> >
> > works, which I copied in the BeanUtils and PropertyUtils classes. As the
> > properties are being copied, if the input value is a zero length string,
> > it is *not* copied.
> >
> > Changing this behavior now would be very likely to break existing code, so
> > I think we need to deal with it. But, your question is more general in
> > scope because the input beans could come from the application as well.
> >
> > > So, I had a couple of ideas for solving this, and I'd like to hear what
> > > people think.
> > >
> > > 1) Modify the present and notPresent tags such that the empty string is
> > > equivalent to null for the purposes of this test, if in fact the
> specified
> > > property is a String. This might break things, though - I'm not sure.
> > >
> > > 2) Define two new logic tags - perhaps empty and notEmpty - which define
> > > emptiness as a property being either null or the empty string. Unlike
> > > present and notPresent, these tags would only work with the name and
> > > property attributes (i.e. not cookie, parameter, etc), since the others
> > > don't really make sense distinct from present and notPresent.
> > >
> > > The second option appeals to me more, because it seems somewhat cleaner
> than
> > > muddying the definition of presence to include type-specific values.
> > >
> >
> > A third option would be to add an "empty" attribute to the <logic:present>
> > and <logic:notPresent> tags, which tells them how to treat empty
> > strings. The default, of course, would be the current behavior.
> >
> >
> > > Comments, anyone?
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > >
> > >
> >
> > Craig
> >
> >
>
>
>
Re: Logic tags and string properties
Posted by Martin Cooper <ma...@tumbleweed.com>.
Picking up on an old thread here (because I'd like to go ahead and fix the
problem :-) ).
If we add an 'empty' attribute to <logic:present> and <logic:notPresent>,
what should the allowed values be?
One option which occurs to me is that "empty='true'" would mean that the
condition is true if the property is an empty string, while "empty='false'"
would mean that the condition is false if the property is an empty string.
To preserve the existing semantics of these tags when the attribute is not
specified, 'empty' would default to 'true' for <logic:present> and 'false'
for <logic:notPresent>.
Is this what you had in mind?
--
Martin Cooper
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, May 23, 2001 9:29 AM
Subject: Re: Logic tags and string properties
>
>
> On Wed, 23 May 2001, Martin Cooper wrote:
>
> > It seems that it is not possible to use the logic tags to test "is this
> > property either null or an empty string?". Using <logic:present>, I can
> > determine that some value is present, but as far as I can tell, there is
no
> > way to test for an empty string. Specifying value="" for tags such as
> > notEqual seems to result in a complaint that a required attribute has
not
> > been specified. (Is this correct, or is this a bug in Resin, the
container
> > I'm using?)
> >
>
> This is ultimately due to a restriction on the way that
>
> <jsp:setProperty name="beanname" property="*"/>
>
> works, which I copied in the BeanUtils and PropertyUtils classes. As the
> properties are being copied, if the input value is a zero length string,
> it is *not* copied.
>
> Changing this behavior now would be very likely to break existing code, so
> I think we need to deal with it. But, your question is more general in
> scope because the input beans could come from the application as well.
>
> > So, I had a couple of ideas for solving this, and I'd like to hear what
> > people think.
> >
> > 1) Modify the present and notPresent tags such that the empty string is
> > equivalent to null for the purposes of this test, if in fact the
specified
> > property is a String. This might break things, though - I'm not sure.
> >
> > 2) Define two new logic tags - perhaps empty and notEmpty - which define
> > emptiness as a property being either null or the empty string. Unlike
> > present and notPresent, these tags would only work with the name and
> > property attributes (i.e. not cookie, parameter, etc), since the others
> > don't really make sense distinct from present and notPresent.
> >
> > The second option appeals to me more, because it seems somewhat cleaner
than
> > muddying the definition of presence to include type-specific values.
> >
>
> A third option would be to add an "empty" attribute to the <logic:present>
> and <logic:notPresent> tags, which tells them how to treat empty
> strings. The default, of course, would be the current behavior.
>
>
> > Comments, anyone?
> >
> > --
> > Martin Cooper
> >
> >
> >
> >
>
> Craig
>
>
Re: Logic tags and string properties
Posted by Ted Husted <hu...@apache.org>.
+1 on an empty attribute
I've been adding logic to my value beans to turn empty Strings back to
nulls when retrieving properties from the database (where I don't permit
nulls), so this would save me that workaround.
"Craig R. McClanahan" wrote:
> A third option would be to add an "empty" attribute to the <logic:present>
> and <logic:notPresent> tags, which tells them how to treat empty
> strings. The default, of course, would be the current behavior.
Re: Logic tags and string properties
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 23 May 2001, Martin Cooper wrote:
> It seems that it is not possible to use the logic tags to test "is this
> property either null or an empty string?". Using <logic:present>, I can
> determine that some value is present, but as far as I can tell, there is no
> way to test for an empty string. Specifying value="" for tags such as
> notEqual seems to result in a complaint that a required attribute has not
> been specified. (Is this correct, or is this a bug in Resin, the container
> I'm using?)
>
This is ultimately due to a restriction on the way that
<jsp:setProperty name="beanname" property="*"/>
works, which I copied in the BeanUtils and PropertyUtils classes. As the
properties are being copied, if the input value is a zero length string,
it is *not* copied.
Changing this behavior now would be very likely to break existing code, so
I think we need to deal with it. But, your question is more general in
scope because the input beans could come from the application as well.
> So, I had a couple of ideas for solving this, and I'd like to hear what
> people think.
>
> 1) Modify the present and notPresent tags such that the empty string is
> equivalent to null for the purposes of this test, if in fact the specified
> property is a String. This might break things, though - I'm not sure.
>
> 2) Define two new logic tags - perhaps empty and notEmpty - which define
> emptiness as a property being either null or the empty string. Unlike
> present and notPresent, these tags would only work with the name and
> property attributes (i.e. not cookie, parameter, etc), since the others
> don't really make sense distinct from present and notPresent.
>
> The second option appeals to me more, because it seems somewhat cleaner than
> muddying the definition of presence to include type-specific values.
>
A third option would be to add an "empty" attribute to the <logic:present>
and <logic:notPresent> tags, which tells them how to treat empty
strings. The default, of course, would be the current behavior.
> Comments, anyone?
>
> --
> Martin Cooper
>
>
>
>
Craig