Well, on the one hand I agree it should be possible to do this, but let me play devil's advocate for a minute.
If we're generating a class from an XML template, the assumption is that we're going to, at some point, be serializing/deserializing that class to/from XML. If that's the case, doesn't it make sense to keep the metadata about that mapping tied closely to the class itself? For instance, .NET does this by embedding the metadata right into the CLR bytecode, which I think is a great idea. That way any XML-aware piece of the system can do the right thing with these classes without any external configuration. What's so wrong about embedding it? "If we expose the meta-data to the users, we are going to regret it..." Hm. Let's say I'm starting from Java, and I want to control how my class is represented in XML... how do I do that without having some knobs I can twist on the metadata? Whether that be in a separate file or in the java itself, I need to be able to have that functionality somehow! (Longer-term, I think that xdoclet tags are the right way to do this stuff.) --Glen > -----Original Message----- > From: Richard Sitze [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 11, 2002 5:33 PM > To: [EMAIL PROTECTED] > Subject: Re: Bean Class/Bean Class Helper Generation > > > +1 to stepping back and designing (ie. cease code-checking on current > direction) > > It's critical that we isolate JAX-RPC implementation details > (Meta-data) > from the classes exposed to the user. We need a design that > reflects this > in place ASAP, and we need to be writing to the design to minimize > unnecessary rework later. I'm all for refactoring, but I'm > even more for > starting off on the right foot for the users. > > If we expose the meta-data to the users, we are going to regret it... > > > +1 on an interface. > > +0 on this specific interface. Those who are dealing with > this section of > code need to agree on this. > > <ras> > > > ******************************************* > Richard A. Sitze [EMAIL PROTECTED] > CORBA Interoperability & WebServices > IBM WebSphere Development > > > > > R J Scheuerle > > Jr/Austin/IBM@IB To: > [EMAIL PROTECTED] > MUS cc: > > Subject: Bean > Class/Bean Class Helper Generation > 03/11/2002 04:14 > > PM > > Please respond > > to axis-dev > > > > > > > > > > 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) > > > >
