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