[morph-developer] FW: Some ideas for the current Morph release
Brought to you by:
orangeherbert,
sgarlatm
|
From: Volanis, A. <AVo...@rs...> - 2005-02-16 18:24:39
|
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 |