why dont you just change it to "isEmpty" or "emptyString" which everyone
knows already? =)
----- Original Message -----
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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
> >
> >
>
>
