Personally, I would think there's a difference between an individual
method returning null, and an entire object being absent.
I also wonder about the idea that "The deliveryAddress is optional, so
can be null."
If I understand the hypothetical, deliveryAddress is optional only if
the user doesn't enter anything into the fields. If they do enter
something, then it is no longer "optional", and the input will have to
go somewhere. So then the ActionForm would need to know how to create
this object "on the fly". I would submit that this is more work than
just creating an empty object to begin with.
>I do not like to change a model bean (model as Model in the MVC
pattern) only for getting it displayed correctly on a JSP page.
What changes would you need to make? If it is a bean, should it not
have a default, empty constructor?
It may also be important to note that most people may not want to put
the actual model bean on the Action Form, but rather a copy. Otherwise
things like "reset", "undo" and general validation can become
problematic.
An approach I'm working on now is to include Struts-friendly, but
generally useful, methods in my model beans, like like reset() and
copyProperties(). (I'm also considering validate() for simple type
checking.)
If I were using model beans that were shared with another
implementation, I would consider subclassing them to add these methods,
and perhaps having copyProperties copy data from the super class to the
Struts-friendly class. In that case, I may also need to add other
signatures, to accomodate the fact that input from a HTML form will
always be string based, regardless of what the ultimate host type.
*********** REPLY SEPARATOR ***********
On 1/18/2001 at 10:52 AM Kok, Arjan wrote:
I have to disagree with you on this point.
Consider for example a Customer Bean with two addresses: mailingAddress
and
deliveryAddress. The deliveryAddress is optional, so can be null. Next,
I
try to display (read only) the Customer properties in a JSP Page. In
the
current situation, before displaying the JSP page, the deliveryAddress
object must exist. That is, I have to create a deliveryAddress with
empty
fields if a deliveryAddress is null, only for letting the Struts tag
(property or write) do it's work. Why not display all requested
properties
of the deliveryAddress as a zero lenght string if the deliveryAddress
is
null. I do not like to change a model bean (model as Model in the MVC
pattern) only for getting it displayed correctly on a JSP page.
I agree that when trying to update or create Customer properties, an
initialized deliveryAddress should be there, but then in the Form Bean.
Arjan Kok
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 11, 2001 6:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-struts/web/test html-multibox.jsp
> html-setters.jsp
>
>
> "Kok, Arjan" wrote:
>
> > Hello Craig,
> >
> > What happens if in the code snippet <html:text
> > property="mailingAddress.street"/> mailingAddress is null?
> I would expect
> > Struts not to raise an exception for initial display when
> mailingAddress is
> > null, because Struts will also not raise an exception when
> street is null.
> > If Struts raises an exception in the former, I would like
> an opportunity in
> > Struts to check if there is a nested bean (e.g. by extending the
> > logic:present tag).
> >
>
> Right now, Struts would throw an IllegalArgumentException
> ("Null property value
> for 'mailingAddress'") if the mailingAddress property is null.
>
> If mailingAddress is not null, but mailingAddress.street is
> null, a null will be
> returned from PropertyUtils.getProperty(), which will
> ultimately display as a
> zero length string in an <html:text> tag.
>
> IMHO this is appropriate behavior. It is up to the
> application designer to
> ensure that all of the property values before the last one in a
nested
> expression are valid and non-null. In Java terms, that means
> the tags expect
> you to have initialized an Address with empty fields, and called
> setMailingAddress() on your underlying bean, as part of the
> initial setup of the
> "outer" bean.
>
>
> >
> > Arjan Kok.
>
> Craig
>
>
