I've been doing a bit of work on PropertyUtils bugs recently and discussing some discrepencies with how simple/mapped properties are handled between the different methods with a couple of the other beanutils committers.
Quoting from Craig McClanahan.... "The standard implementations of expression evaluation (JSTL 1.0/1.1, JSP 2.0, JSF 1.0/1.1) all conform to the way that BeanUtils currently works -- if the object you pass implements Map, it is *always* treated as a Map." There are currently some discrepencies in beanutils where the above statement isn't followed - but, from the discussion over on commons, its likely that in a future version of beanutils it will be changed so that it is always consistent with the above statement. Niall ----- Original Message ----- From: "Michael McGrady" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, July 15, 2004 2:49 AM Subject: Re: LabelValueBean and BeanMap with <html:radio> and <logic:iterator> for indexed properties > Thanks, Joe. I expect you are right, but it is comforting to hear it. > > Michael > > At 04:06 PM 7/14/2004, you wrote: > >Michael: > > > >This is ultimately a function performed by commons-beanutils, not Struts > >itself. Specifically, o.a.c.beanutils.PropertyUtils has a method, > >"getProperty(Object, String) which returns the object value of the bean > >property. (Internally, that's actually forwarded to > >getNestedProperty(Object, String) but the end result is the same...) > > > >Anyway, while it's not explicit in the docs, it is explicit in the code -- > >if the Object passed to PropertyUtils implements java.util.Map, then the > >String passed in is used as a key to the map to get the value to > >return. As much as you trust the developers of beanutils to maintain > >backwards compatibility, you can count on this. I'd say you're pretty safe. > > > >Joe > > > > > >At 3:28 PM -0700 7/14/04, Michael McGrady wrote: > >>I am using my version of a BeanMap built for instrumentation, cf. > >>http://wiki.apache.org/struts/StrutsCatalogMappedBeans, and am putting a > >>series of java.util.LinkedLists holding > >>org.apache.struts.util.LabelValueBeans into the BeanMap via > >>setProperty(Object key,Object value). I am then accessing the lists via > >><logic:iterator> in Struts radio tags (where "eclipse" is a key in the > >>BeanMap holding a list of LabelValueBeans) as follows: > >> > >> > >> <logic:iterate id="row" name="layouts_schemes" > >> property="eclipse"> > >> <html:radio property="scheme" value="value" idName="row"/> > >> <bean:write name="row" property="label"/> > >> </logic:iterate> > >> > >>This works great! However, I am not sure that this behavior will be > >>guaranteed in the future, since it is not documented in the docs. > >> > >>In the docs, the property for iterator is "defined" as the > >> > >> "Name of the property, of the JSP bean specified by name, whose > >> getter returns the collection to be iterated". > >> > >>Obviously, my code sneaks in the value of the property attribute as the > >> > >> "Name of the key in the BeanMap which returns the Collection > >> saved is scope as "layouts_schemes" > >> > >>Trust me, if I change the property value to a different key in the > >>BeanMap, I do get a different collection (List) from the BeanMap on the > >>page. My question is whether this will be guaranteed in the future. Or, > >>is this an anomaly that I cannot count on in the future? Anyone have an > >>inkling on that? > >> > >>Thanks! > >> > >>Michael > >> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >-- > >Joe Germuska > >[EMAIL PROTECTED] > >http://blog.germuska.com > >"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; > >I'll know I'm in the wrong place." > > - Carlos Santana > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
