Actually I like "emptyString" very much !
I use the same keyword in my validation properties (in the mapper-config.xml
:)
Just a couple tips which may or may not be relevant:
1. I had to distinguish empty strings from blank strings in order to provide
finer control over validation and conversion.
2. Having a default value for some properties may lead to some troubles if
there are a choice of multiple attributes with overlaping semantics. For
example, suppose an attribute 'emptyString' defaults to true, but that you
also have another attribute 'null'. Depending on how you code your logic,
setting 'null' to true may lead to both 'emptyString' and 'null' to be true
at the same. Again, depending on how it's coded (e.g. the order in which you
test the attributes, whether you set one to false when setting the other to
true, ...) you may have unexpected behavior.
Fr.
-----Original Message-----
From: Jonathan Asbell [mailto:[EMAIL PROTECTED]]
Sent: 25 June 2001 14:06
To: [EMAIL PROTECTED]
Subject: Re: Logic tags and string properties
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
> >
> >
>
>
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
