> P.S. What do you mean the equals method "needs work"?
> I think its pretty good for getting whipped off in 10 minutes at the
interop.
> :-)
Then you can fix it up to make it work correctly for array components. I
already fixed the potential NPE problems.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Tom Jordahl
<tomj@macromedia. To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
com> cc:
Subject: RE: Bean Class/Bean Class
Helper Generation
03/11/2002 05:00
PM
Please respond to
axis-dev
-1 on moving the meta data out of the bean class and in to some other
place.
I find this mechanism simple and easy to understand and use (hey, what do
you know, I coded it). I do not think a helper class would be as
straightforward, nor would it be as easy for users to grasp quickly. I
don't see the advantage of emitting (another!) class.
I also don't see how we are limited by this architecture. It has already
proven its flexibility by getting extended (in a cool way!) by Glen. I see
nothing that would prevent us from dealing with "future expansion".
P.S. What do you mean the equals method "needs work"?
I think its pretty good for getting whipped off in 10 minutes at the
interop.
:-)
--
Tom Jordahl
Macromedia
-----Original Message-----
From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 11, 2002 5:15 PM
To: [EMAIL PROTECTED]
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)
