getProperty displays "null"

[JGH]

How do I keep the jsp:getProperty tag to not display null if the value is
null. That seems really braindead in the first plafce.

For example, I have a search form and I want the search values to reappear
on the search form .

I have:

<INPUT name="lastname" ... value="<jsp:getproperty name="myBean"
property="last_name">">


But the data entry field has the word "null" in it if the user does not
enter a last_name.

 

[Ryan Stewart]

How do I keep the jsp:getProperty tag to not display null if the value is
null. That seems really braindead in the first plafce.

For example, I have a search form and I want the search values to reappear
on the search form .

I have:

<INPUT name="lastname" ... value="<jsp:getproperty name="myBean"
property="last_name">">


But the data entry field has the word "null" in it if the user does not
enter a last_name.

Initialize it to an empty String.

 

[kaeli]

How do I keep the jsp:getProperty tag to not display null if the value is
null. That seems really braindead in the first plafce.

If you want defaults, then in your bean constructor, set defaults.
It's just returning Object.property.toString(). For a null object, that value
happens to be the string "null".

If you are adverse to setting defaults, you can do what I did.
I have a static utility class with a method called nvl(object, string) to
emulate Oracle's nvl function. You send it an object and the string you want
returned if the object is null. It returns back object.toString or the
default value you specified.

So, the tag would be a little different.

<INPUT ... value="<%=Utility.nvl(myBean.getLast_name(),"")%>">

HTH
--

 

[JGH]

Initialize it to an empty String.

Kind of defeats the purpose of the bean then, doesn't it? I might as
well just set the value from the Request if I'm going to do that.

 

[JGH]

If you want defaults, then in your bean constructor, set defaults.
It's just returning Object.property.toString(). For a null object,
that value happens to be the string "null".

I would think everyone would be adverse to setting defaults because ""
is not the same as the null value. If you're writing a bean, you'd think
you'd want some way to distinguish between a value that has been set to
"" vs one that has not been set. That might be important in some
circumstances.

I guess now we are getting into philosophical issues but why would
toString return the string "null"? It seems to me that it makes sense to
return "" if you're explicity calling toString on a null value. That
doesn't prohibit you from testing whether the value is null.

If you are adverse to setting defaults, you can do what I did.
I have a static utility class with a method called nvl(object, string)
to emulate Oracle's nvl function. You send it an object and the string
you want returned if the object is null. It returns back
object.toString or the default value you specified.

Lame. Well, I don't mean your solution is lame. Thanks for the tip. I
mean it seems lame that it's necessary.

I'm self-taught in java and fairly new so maybe I'm way off.

 

[kaeli]

I would think everyone would be adverse to setting defaults because ""
is not the same as the null value.

That is exactly why I don't set defaults.

I guess now we are getting into philosophical issues but why would
toString return the string "null"?

Because the object itself is null. It can't print that. Actually, it can't
even run it. Null is exactly that -- NULL. It doesn't point to anything.
There is no object at all to reference. If this were anything but toString(),
calling a method on a null reference would result in a runtime exception.
You're lucky it prints "null".

Example:
Integer i;
int i = i.intValue(); // NullPointerException

I have my own methods for things that that, too, that return an empty string
if the object is null.

This is Java. It takes a lot of it's stuff from C. Go make some stuff in C
and find out how lucky you are that it does what it does and doesn't core
dump all over. *LOL*

It seems to me that it makes sense to
return "" if you're explicity calling toString on a null value.

To you, maybe, but there is a BIG difference between an empty string and a
null value. toString prints what it has. It doesn't make up the value. It
isn't going to print an empty string when it doesn't have an empty string. It
has a null object which is not even a String. It's nothing. Nada. It may have
been supposed to be a String, but for all the JVM knows, it might have been
supposed to be an Integer or ArrayList. All it sees is a call to toString
from a null reference.

If you don't like the default behavior, override toString in your objects and
make a utility function for Java data types, like I did.
Mine returns 0 for numeric types (i.e. Double or Integer) and "" for anything
else.

Java is very flexible. If you don't like something, override or change it.

--

 

[JGH]

That is exactly why I don't set defaults.


Because the object itself is null. It can't print that. Actually, it
can't even run it. Null is exactly that -- NULL. It doesn't point to
anything. There is no object at all to reference. If this were
anything but toString(), calling a method on a null reference would
result in a runtime exception. You're lucky it prints "null".

I totally disagree. It would make *sense* to generate a runtime
exception. That would be consistent with what happens if you call a
method on a null value otherwise. But since it's not going to do that ,
and I can understand why they wouldn't want to do that, then it should
return "".

Maybe it's the setProperty="*" thing that's broken. After all, http is
ppassing in a value for the lastName parameter:


<jsp:useBean id="myBean" scope="page" class="myBeanClass" />
<jsp:setProperty name="myBean" property="*" />

<FORM ...>
<INPUT name="lastName" value="">
....
</FORM>



You click the submit button on that form, the scritp isn't going to get