The bug you mention may be the problem. The property we were accessing was read-only, i.e., there was only a getter method and no setter method. We'll get the nightly build of Common BeanUtils and try it out.
>From an implementation point of view, we may use different implementation of Map, rather than HashMap, but we want the Map interface functionality. I'll look at the BeanUtils code and see what we can do in terms of enhancing MappedPropertyDescriptor. Does the nightly build of Struts use the nightly build of Common BeanUtils? Thanks, Viral -----Original Message----- From: Rey Francois [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 30, 2001 11:45 PM To: 'Struts Users Mailing List' Subject: RE: Hashmaps and string keyed properties Viral, Could you be more precise on the runtime exception you get? What you are trying to do should be possible with the Common BeanUtils. However there is a bug that is fixed only in the nightly build of the Commons BeanUtils. This bug is about the inability to recognize the read-only mapped properties in some cases. Perhaps you will resolve your problem by taking the latest build of the commons BeanUtils (commons-beanutils.jar). The second thing you want to do is, if I understand well, the ability to get the whole map of values, like it is possible in the JDK to get an array of values for an indexed property using a no-arg getMethod. This is actually not implemented. However the class MappedPropertyDescriptor in BeanUtils is implemented in a way that makes it easy to do so. If you feel like it, you can implement this feature yourself and perhaps submit the code for inclusion in the BeanUtils. It should be easy to implement, have a look at how the JDK IndexedPropertyDescriptor is implemented in Java and try to do the same in MappedPropertyDescriptor. One concern however in implementing this: is the type Map the best choice as a return value? The problem with Map is that it does not enforce the use of String as keys. The other problem was that it forces the use of standard Java collections (for example the JGL HashMap could not be used). However I cannot think of any better alternatives than Map... The third thing you talk about, I'm not sure what. Using the current convention for nested properties, you could do this: method(key1).prop2(key2).prop3(key3), but I'm not sure that's what you want. Hope this helps, Fr. -----Original Message----- From: Viral V. Tolat [mailto:[EMAIL PROTECTED]] Sent: 31 October 2001 04:48 To: '[EMAIL PROTECTED]' Subject: Hashmaps and string keyed properties Three questions. First, we're trying to get the following to work with the Struts nightly build <bean:write name="SomeForm" property="method(key)"> where SomeForm implements String getMethod ( String key ). We get a runtime error in the write tag for this and we can't figure out why. Any suggestions? Do we need the Bean Utils with indexed string contributor extension? But if we take this, does it merge with the current BeanUtils from Commons? Second, we'd like to be able to access a HashMap directly from the taglibs, similar to how an Array can be accessed. So we'd like to be able to do the same as above except that HashMap getMethod() returns a HashMap and doesn't take an argument. And lastly, we'd like to be able to nest Hashmaps and then have something like <bearn:write name="SomeForm" property="method.key1.key2.key3"> where getMethod returns a HashMap but then key1 through key3 index into successive Hashmaps or other JavaBeans. Essentially we'd like to wrap our form beans around a hashmap. We'll then write code in our action beans to convert the hashmaps to and from Java business objects. We just don't see alot of value in creating a FormBean for every domain object of which we have several hundred. Thanks. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> ************************************************************************ 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
