One thing you might want to consider is combining any such helper
class with a BeanInfo class that users might have already created
for their beans. Having 2 classes that contain metadata about a
bean isn't as clean as 1.
-Dug
R J Scheuerle Jr/Austin/IBM@IBMUS on 03/11/2002 05:14:50 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Bean Class/Bean Class Helper Generation
There have been several recent changes to the Bean Class generation to
support more advanced
xml features...namely attributes.
I applaud the new functionality, but we need to step back and consider a
more flexible architectural direction.
I would like to see all of the meta data information removed from the java
bean class and placed in a
Helper class that extends a Helper interface. Here is a first pass at the
Helper interface:
interface Helper {
public org.apache.axis.description.TypeDesc getTypeDesc();
public org.apache.axis.encoding.Serializer getSerializerAs(String
mechanismType);
public org.apache.axis.encoding.Deserializer getDeserializerAs(String
mechanismType);
}
The generated bean class should contain ONLY the getters/setters describing
the bean (and perhaps
the equals() method...which needs some work). This would adequately
decouple
the logical bean from the serialization/deserialization of the bean.
The BeanSerializerFactory/BeanDeserializerFactory could be tweaked to
always look for a corresponding
Helper class to find the meta data or find the custom
serializer/deserializer. The generic serializer/deserializer
classes should use default behaviour if the helper class is not available.
(In fact I am in favor of having
separate meta data aware serializers/deserializers.)
Separating the bean and the bean helper would allow users to provide custom
Helper emitters to
add custom serializers etc.
Please comment.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
