Thanks, Lauren, for taking the time to clarify this a bit more. Having
said that, let me address some of your reply below.
Regards
Werner
Lauren Bish wrote:
> Because the domain classes may change and evolve (for example, I may want to
> add property change support to a given bean - although I have since come to
> the opinion that it is better to use IOC to put that kind of logic outside a
> bean).
>
> Because the generated descripter code does not seem intuitive to me with
> regards to modifying it.
>
> We have a lot of POJO value objects that get passed around, in the client,
> and between the client and the server via SOAP.
Can I take it that you use Castor as data binding tool tightly
integrated with your SOAP stack ?
> We store some local
> configuration beans in XML to persist them and read/write them back and
> forth using Castor.
>
> It just seemed simpler to maintain the mapping file - although there is a
> problem with that approach (as there is with anytime you use XML for such a
> purpose); when you refactor the bean, e.g., change the name of a property or
> the type, you have to remember to go and change it in the mapping file also.
That's why I'd personally would not use a mapping file when starting
from an XML schema. When a schema chanages, I'd simply regenerate the
classes ... et voila. No manual intervention required, no need to
rememember that you have to (again manually) keep the domain objects (as
generated) and the mapping file in sync.
> Most refactoring tools (any?) won't do this for you in XML. We have unit
> tests for the mapping though - so if a bean property changes then
> theoretically the tests will catch not changing the mapping also.
>
> As for how to go from XSD to a Castor mapping file, when I had to wrap a
> third party XML API, I used their XSD to generate the beans and the class
> descriptors, then I used the MppaingTool to generate the mapping from the
> combination of the bean and its descriptor.
There's an option on the XML code generator that will enable creation of
a mapping file during code generation. In addition, when you use the
Castor (Un)Marshaller to (un)marshal data to/from XML, please do
remember that Castor XML internally will convert your mapping files into
descriptor classes.
>For some reason I could not get
> the Mapping Tool to work from the command line ...
I'd like to know about this if this is still the case, to be honest.
> so I resorted to this:
>
> try
> {
> MappingTool tool = new MappingTool();
> tool.setForceIntrospection(false);
> tool.addClass("com.somecompanyname.somepackagename.SomeClassName");
> tool.write(new FileWriter("XMLTestMapping.xml"));
> }
> catch(MappingException ex){ fail(ex.getLocalizedMessage());}
> catch(IOException ex){ fail(ex.getLocalizedMessage());}
>
> Once I had the mapping it was fairly easy to test and maintain - and as I
> said before, it seemed more intuitive than the descriptor code. That is not
> a dig at the Castor developers, but it just seemed that way to me - maybe I
> am just a little slow. Once I understood the mapping files most were pretty
> straightforward until you got into the more complex aspects of them - such
> as collections, etc. - and even then they were okay. Our beans are pretty
> simple in that regard.
>
> It is all a trade off - I can imagine some cases where the generated code
> would be better, especially if you had some kind of automated generation
> setup, but for our simple use the mapping files are simpler and sufficient.
>
>
>
> !> -----Original Message-----
> !> From: Werner Guttmann [mailto:[EMAIL PROTECTED]
> !> Sent: Wednesday, November 08, 2006 4:43 AM
> !> To: dev@castor.codehaus.org
> !> Cc: user@castor.codehaus.org
> !> Subject: [castor-user] RE: [castor-dev] xsd file --> mapping file
> !>
> !>
> !> Why would you want to create a mapping file, when Castor XML's code
> !> generator creates domain classes and *descriptor classes for you (that
> !> basically hold the same information as a manually provided mapping would
> !> do) ?
> !>
> !> Werner
> !>
> !> > -----Original Message-----
> !> > From: omikron [mailto:[EMAIL PROTECTED]
> !> > Sent: Mittwoch, 08. November 2006 13:37
> !> > To: dev@castor.codehaus.org
> !> > Subject: [castor-dev] xsd file --> mapping file
> !> >
> !> >
> !> > I've got .xsd file, which represents client-server protocol.
> !> > How to create mapping file from it?
> !> > --
> !> > View this message in context:
> !> > http://www.nabble.com/xsd-file---%3E-mapping-file-tf2594984.ht
> !> > ml#a7237702
> !> > Sent from the Castor - Dev mailing list archive at Nabble.com.
> !> >
> !> >
> --
> Internal Virus Database is out-of-date.
> Checked by AVG Free Edition.
> Version: 7.5.430 / Virus Database: 0.0.0/0 - Release Date: <unknown> 12:00
> AM
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
