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
>
subclassex2.jar
Description: subclassex2.jar
