That's a neat idea, Erik. I think that Robert could maybe implement what he wants that way. Here's how:
1) Write the subclass of VehicleType that contains the business logic. Let's call it VehicleTypeManual.
2) Create an empty descriptor that extends VehicleTypeDescriptor, as Erik suggested. Call it VehicleTypeManualDescriptor.
3) Write a binding file that remaps CarType (or Car) and SUVType (or SUV) something like this:
<complexTypeBinding name="CarType"> <java-class><extends>VehicleTypeManual</extends></java-class> </complexTypeBinding>
I'm not positive that this will work (I've never used this feature of the binding file), but it's worth a shot. Give it a try and let us know how it goes.
Rhett
Ostermueller, Erik wrote:
Rhett wrote:
In my experience, you can't add business logic to Castor generated
classes in any sort of a maintainable way. It's
better to treat them as a data access interface and put the logic
somewhere else.
Rhett, Keith showed me a trick one time that comes real close to this.
If you generate Note.java and NoteDescriptor.java, then you can do the following:
//hand coded class! public class NoteSubclass extends Note { //add your _transient_ fields and members here } public class NoteSubclassDescriptor extends WombatDescriptor { //don't add anything here }
I've attached an example that used castor-0.9.3.9.jar
> -----Original Message-----
> From: Rhett Sutphin [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 20, 2003 8:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] Re: Abstract super classes > and element class mapping
> > > [EMAIL PROTECTED] wrote:
> > I now realize that SourceGenerator is not creating > subclasses for any > > of the abstract types when I have element mapping > enabled. I will > > have to switch back to type mapping for the time > being until I get > > clarification on the element mapping issues. It > seems to me that > > SourceGenerator should create abstract shadow classes > for every > > abstract type. It should also create shadow classes > for subclasses of > > abstract types too.
> > > > e.g.
> > > > VehicleType (abstract class)
> > Vehicle (abstract subclass of VehicleType)
> > > > CarType (abstract subclass of Vehicle)
> > Car (subclass of CarType)
> > > > SUVType (abstract)
> > SUV (subclass of SUVType)
> > Hi Robert,
> > The classes you are calling "shadow" subclasses, > aren't. They are the classes that map to the concrete > elements in your schema. The difference between 'type' > mapping and 'element' mapping is that in 'element' > mapping _all_ complex elements get a class. In 'type' > mapping, only top-level elements and elements with an > anonymous complexType get a class. > > I don't know what you mean when you said in your > earlier message:
> > > This allows
> > you to put your custom logic in the subclass and not > have to worry about it > > getting overwritten next time you regenerate your > classes from your schema.
> > As I read this, it isn't true (unless there's some > major new behavior in 0.9.5.2 that I'm unaware of). > The element classes will be regenerated along with all > the rest, so long as you keep using 'element' mapping. > If you switch to 'type' mapping, they won't be > overwritten, but they also _won't be used_. The > descriptors will change and, if you examine the > complexType classes closely, you'll see that return > types, parameter types, and the class hierarchy will be > different too.
> > So, how do you get the effect you want? In my > experience, you can't add business logic to Castor > generated classes in any sort of a maintainable way. > It's better to treat them as a data access interface > and put the logic somewhere else. > > HTH,
> Rhett
> > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail > to [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
