[morph-developer] FW: Some ideas for the current Morph release

[Volanis, A. <AVo...@rs...>]

This is bouncing from the morph-user list today. I am forwarding to you =
directly as well as the dev list.=20

-----Original Message-----
From: Volanis, Alexander=20
Sent: Wednesday, February 16, 2005 1:18 PM
To: 'mor...@li...'
Subject: FW: Some ideas for the current Morph release

Hi Matt,

I really like where you are going with this release. The new features =
work well and collapsing the SelectivePropertyNameMatchingCopier into =
the PropertyNameMatchingCopier does seem like the right thing to do.

Looking at the changes that you are in the process of making in =
PropertyNameMappingCopier I have one observation to make. I have used an =
OrderedMap as input to the setMapping() method to control the order of =
property copying. In some specialized cases the order in which =
properties are copied from one object to another is significant. Here is =
for example my reason for specifying the order. One of the objects I had =
to copy contained collections of beans that had ID properties. Within =
the rest of the object there were other objects that made references to =
the aforementioned beans. The references were plain object references =
that were established during the construction of the source object by =
reading an XML file that contained IDREFs. As I transformed the source =
objects I had to maintain the same references where applicable. My =
solution was to make an abstract converter class that all my copiers =
were derived from and look for the ID property present on any =
destination object. If there was one I collected the ID and the object =
reference in a Map. As the transformation progressed I would encounter =
the objects that needed to resolve the references to the new transformed =
objects. At that time I would get the required object references from my =
previously polulated Map and set them in my new referencing objects. =
This was only possible if the order of copying was strictly controlled =
by my mapping specifications.

I believe there is a need to provide an OrderedHashMap implementation to =
support this functionality. The JDK 1.4 LinkedHashMap provides this =
functionality for me. You should probably consider using this in your =
BiDirectionalMap implementation as well. It may make sense to replace =
all Maps with something like that were there is a chance that a mapping =
order has to be preseved. At least there should be some way to specify =
that iteration order is significant and has to be maintained. In some =
cases it seems easy to just create a new plain HashMap from the one =
specified as input but if you do this the iteration order cannot be =
preserved. I find at least a couple of SF.NET projects that already =
provide this type of Map. Castor also has an OrderedHashMap to maintain =
JDK 1.2 and 1.3 compatibility. I also know Jacarta commons has a =
SequencedHashMap that works. It may be possible to use a fa=E7ade that =
can expose the best available HashMap implementation instead.

Another comment has to do with the "implicit properties". Using URI =
notation you could replace the string for the IMPLICIT_PROPERTY_CLASS =
with "urn:morph:properties:class" instead of just "class". This will =
guarantee that there will be no collisions with existing bean =
properties.

Finally one more observation. I think the ReflectionInfo class should =
also look for methods of the form addPropertyName(ObjectType arg) and =
addPropertyName(int index, ObjectType arg). These are common in cases of =
collection properties that are managed as arrays. Castor objects are =
full of these and to work with them I had to enable the Castor extra =
collection methods that give access to the underlying collection by =
reference. The reason I had to do this was that arrays (which is what I =
get otherwise) do not have a GrowableContainerReflector and cannot have =
elements added if they are not already sized to the necessary =
dimensions. If the ReflectionInfo can detect the presense of =
addPropertyName methods we can handle arrays as if they have a =
GrowableContainerReflector. In addition to getting the arrays to grow as =
needed it provides type checking that I lost when I had to use the =
Castor collection references.

I may do some work on this last topic myself if I have some free time =
(which has been severely limited lately). Let me know if there is =
anything that I can pick up from your TODO list.

Alex