I have noticed the discussion about <logic:present> and <logic:notPresent> which
I just found out about. I assume this means that the Tag Lib Guide on the
Struts site is either buggy or its on the todo list :). My apologies if it is
the latter, I do know how documentation can be put off. :)
On a related note, I have just started using some of the other logic tags
(namely match, notMatch and equals) and notice that they throw JspExceptions's
when request parameters or java beans aren't there or null. I was curious to
find out why this semantic was choosen. The behavior that I expected was
something along the lines of :
"anything" equals nothing or null yields false, not a thrown JspException
I guess i could do something like this:
<logic:present parameter="aformfield">
<logic:match parameter="aformfield" value="myvaluetocompare">
...
</logic:match>
</logic:present>
but could be a lot of work for something that could be implicit in the match et
al. tags.
just curious...
mark
Mark R Mascolino
Technology Missionary
The Procter & Gamble Co.
[EMAIL PROTECTED]
Internet Mail Message
Received from host:
"Craig R. McClanahan"
<[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
cc: (bcc: Mark Mascolino-MR/PGI)
05/23/01 12:29 PM Subject: Re: Logic tags and string
properties
Please respond to
struts-dev
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
