Recent changes to feature-requests

Add CloningConverter implementation

2008-08-21T18:13:58Z

Will call public Object clone() if available.

Add Immutable interface

2008-08-21T16:41:47Z

The addition of an Immutable marker interface will allow Morph clients to guide deep transformations to prefer conversion for immutable types. Rather than encourage clients to couple their code to Morph explicitly, AOP introductions will be recommended.

Improve error messages for nested transformations

2007-04-13T22:12:04Z

When an error occurs during a deep copy of an object graph, the error messages are confusing. Here is an example:

net.sf.morph.transform.TransformationException: Error copying source [com.spider.cms.hdao.impl.PerformanceChartHDao@1, com.spider.cms.hdao.impl.PerformanceChartHDao@2, com.spider.cms.hdao.impl.PerformanceChartHDao@1] (class org.hibernate.collection.PersistentList) to destination [com.spider.cms.hdao.impl.PerformanceChartHDao@1, com.spider.cms.hdao.impl.PerformanceChartHDao@2, com.spider.cms.hdao.impl.PerformanceChartHDao@1] (class org.hibernate.collection.PersistentList) at net.sf.morph.transform.transformers.BaseTransformer.copy(BaseTransformer.java:402) at net.sf.morph.transform.transformers.SimpleDelegatingTransformer.copyImpl(SimpleDelegatingTransformer.java:245) at

It would be nice if we could spit out something better like "Error copying property some.nested.path where source was ___ and destination was ___" or perhaps "Error copying property 'path' of object at path 'some.nested' where source was __ and destination was ___"

Right now the error message looks like it could be something wrong with Morph when really that's not the case at all. The error messages need to give more context of where we are in the graph that the error is happening.

Ensure converters can convert Morph's wrapper types

2005-04-19T00:13:06Z

Need to make sure that converters can handle
transformations both to and from one of Morph's own
wrapper types. This type of request wasn't originally
considered because the way these types were originally
envisioned to be requested was using the
Reflector.getWrapper method.

Support addPropertyName methods in ObjectReflector

2005-02-20T13:55:35Z

From Alex Volanis:

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.

Serialization support

2005-02-13T01:13:10Z

Make objects in the framework implement Serializable,
and mark transient fields appropriately

JDBC package

2005-02-13T01:12:00Z

Create a new JDBC package which allows transformations like

Converters for ResultSets to Maps, ResultSets to Lists,
etc. Add a comparison of this new package to iBATIS
SQL maps to the homepage and/or reference document.

JFreeChart example for the Context chapter

2005-02-13T01:10:19Z

Add to the reference manual an example of passing an
HTTP request to a JFreeChart controller w/o dependence
on Servlet API by using Contexts.

HTTP request parameters to object graph

2005-02-13T01:07:58Z

Include an example of converting HTTP request
parameters into an object graph in the reference document.

Include WebFilter in reference document

2005-02-13T01:05:55Z

Include WebFilter in reference document