Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 11154 invoked from network); 27 Nov 2001 06:00:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Nov 2001 06:00:30 -0000 Received: (qmail 20367 invoked by uid 97); 27 Nov 2001 06:00:34 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 20333 invoked by uid 97); 27 Nov 2001 06:00:34 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 20311 invoked from network); 27 Nov 2001 06:00:33 -0000 Message-ID: From: Elli Albek To: Jakarta Commons Developers , "'struts-user@jakarta.apache.org'" Subject: RE: PropertyUtils & dot notation Date: Mon, 26 Nov 2001 21:57:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N We are having exactly the same problem. Our suggestion was to have some plug in the action Servlet to specify the classes that will handle the beans mapping, so we can use our own. This can be done either by sub classing the action Servlet or by having a service provider API that will allow you to register the implementation in the Servlet configuration files. I am not happy to take the code and modify it, this means that every code change in apache requires manual merge to our code base. Having a hook to the system can be more robust solution. E -----Original Message----- From: Rey Francois [mailto:Francois.Rey@capco.com] Sent: Friday, October 19, 2001 12:50 AM To: 'struts-user@jakarta.apache.org' Cc: Jakarta Commons Developers Subject: RE: PropertyUtils & dot notation The things you're talking about (making the getProperty return null instead of throwing an error when a nested property is null, and making the setProperty creating a nested object in the same situation) are indeed not supported within struts or within the commons BeanUtils. As you said, there is no hook to extend and do so. I agree this is definitely a pain to have to deal manually with these situations. The solution for you would be to either keep using your own framework for that part, or to modify/extend yourself the commons/struts BeanUtils, and perhaps submit these enhancements to the list (I think a few people could benefit from this as well). However you must make sure these enhancements preserve backward compatibility. This will allow you to have these enhancements available throughout the whole Struts framework, including the form tags. This also means you have to work this out behind a static class that has cached PropertyDescriptors, and static classes are not that easy to extend! Fr. -----Original Message----- From: Matt Smith [mailto:msmith@dorado.com] Sent: 17 October 2001 11:05 To: struts-user@jakarta.apache.org Subject: PropertyUtils & dot notation This question has to do with PropertyUtils, so it might be more appropriately posted to the Commons mailing list, but they don't have a "User" list so I'm starting here. My company currently has an page generation framework we developed in-house, and I'm looking at replacing it with Struts. I, like some of the users I've seen on the mailing list, deal with large multi-page forms with many (sometimes hundreds) of fields, and I really don't want to code setters & getters for all of them. At first I was particularly worried about the apparent tight coupling of ActionForms to a particular HTML form, but the dot-notation of referencing nested bean properties seems to take care of that nicely. We implemented a very similar system of dot-notation that used reflection, etc, in the same way, but we made some slightly different choices and I'm hoping someone can help me with how I could achieve the same functionality with the struts version. In PropertyUtils.java, get/setNetstedProperty throw IllegalArgumentExceptions if any of the getters return null. So if you try to get a.foo.bar, and getFoo() returns null, then an exception will be thrown. Likewise, setting a.foo.bar will fail. The choice we made was that when you're getting, if anything along the path returned null, then the whole expression was just assumed to be null, and that was fine. so if getFoo() is null, then getting a.foo.bar is null and that's kosher. I assume this is solvable with struts, and that somehow I can ignore the exception. (I just haven't found any hooks into that part of the framework yet). The thing I'm more worried about is object creation - we have things set up so that on sets (and sets only), intermediate objects will be created automatically. So if you try to set a.foo.bar, and getFoo() is null, then foo will be created for you so that bar can be set. How is this normally dealt with in Stuts? Seems like if you have a large object graph that you're trying to deal with in a general way (letting the HTML people move fields from page to page, etc), then having to hard-code object creation would be a huge pain. Thanks for your time, -Matt ************************************************************************ 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 *********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org -- To unsubscribe, e-mail: For additional commands, e-mail: