Thanks Craig for integrating this in the commons and adding some unit tests.
Just a few random comments off my head....
- I like the name of Mapped properties too, in fact I almost chose it as
well. The reason I didn't use it in the end is that it's less concise than
StringKeyed: a Map can use any object as a key, not just Strings.
- I never implemented the feature of looking for a method of the form Map
getProperty(String key). However I have implemented the class
StringKeyedPropertyDescriptor (now MappedPropertyDescriptor) in a way that
will make it easy to do so in the future, mainly by imitating the
IndexedPropertyDescriptor of Java. Anybody looking at implementing this
should look at how IndexedPropertyDescriptor is implemented in Java and try
to do the same.
- The reason I never implemented support for get/set methods using Maps was
double: I needed to have something working quickly and this feature was not
needed, and I wasn't sure also that Map was the best choice. The problem I
had with Map was that it does not enforce the use of String as keys. This
may become a source of problems when iterating over the map in order to
discover what properties are defined. The other problem was that it forces
the use of standard Java collections (for example the JGL HashMap could not
be used). I did not take any time to think further about these issues, and
whether we should worry about them. However I cannot think of any better
alternatives than Map...
- About the problem of listing the mapped properties of a bean: I definitely
think the BeanInfo is a very attractive way to do this. But the big problem
is that we cannot use its method PropertyDescriptor[]
getPropertyDescriptors(). This is because the class MappedPropertyDescriptor
does not derive from PropertyDescriptor but from FeatureDescriptor. I could
not find a way to go around this. I could not inherit from
PropertyDescriptor because of some behavior I could not prevent in its
constructor (I can't remember exactly what, but it had to do with the way of
discovering the accessor methods). This is where the bean specification
could be enhanced in order to support custom property types...
- There is a need to distinguish the concept of a multi-valued property
based on a map (one property name, multiple values stored in a map) and the
concept of dynamic properties, which is for me a set of dynamically defined
properties (several property names, each having their own value). Both can
be implemented with the Mapped properties we talk about here. But I have the
feeling that this double semantic/use of the Mapped properties may lead to
some problems later on...
Fr.
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: 22 August 2001 00:03
To: [EMAIL PROTECTED]
Subject: Re: Proposal: String indexed properties
On Mon, 13 Aug 2001, Gregor Rayman wrote:
> Hi all,
>
> I've used the source code from Fracois Rey and have patched the
> PropertyUtils and BeanUtils to support string indexed properties.
>
> e.g. property prop(id) gets translated into getProp("id") and
setProp("id",
> value)
>
> It works in combination with integer indexed and nested properties.
> It will probably not work correctly, if the index strings contain
> the separator characters ".", "[", "]" or "(", ")".
>
> I have not done any unit tests yet, I've only tested it in my
> Struts based application.
>
>
> I have no idea how to sumbit code to Jakarta, so I send the sources as
they
> are
> to this mailing list. If you'd like the idea, I will clean them up, test
> them etc.
>
I've just checked in updates to the BeanUtils package based on your
contributions, plus some unit tests. As we discussed earlier, I changed
the names from "String Keyed" to "Mapped".
Thanks for the contribution!
> Possible improvements might be:
> - escape syntax which would allow separator characters in the index
string
Yah, this is pretty important -- fortunately, it's fairly easy.
> - allow using Map, if there are no getProp(String) and setProp(String,
...)
> but there is Map getProp();
>
This actually corresponds to the way that Dmitri's JXPath stuff looks
at things, so it's a good idea as well. It should also be fairly
straightforward.
> --
> gR
>
Craig
************************************************************************
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
***********************************************************************
