Hello Ted, Thanks for your response. However, I made a distinction between displaying fields of a Model bean on a JSP and updating or creating a Model bean on a JSP. For updating or creating a Customer an initialized deliveryAddress should be there in the Form Bean, no doubt about this. Note that the Struts framework makes the same distinction: only for updating or creating Model beans a Form Bean is needed (so for HTML Forms). However, when I want to display the fields of a Model bean I do not like to change the Model bean. In our application we use Entity Beans (EJB), and Entity beans can have a deliveryAddress with value null (when the foreign key relating a deliveryAddress to a Customer in the Customer table is null). Regards, Arjan. > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 18, 2001 12:55 PM > To: Struts Dev > Subject: RE: cvs commit: jakarta-struts/web/test html-multibox.jsp > html-s etters.jsp > > > 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 > > > > > > >
