Dunno if you ever got a response....
Whether or not you want to create classes for these is totally up to
you - you will likely find, for example, that the minimum case of
what you'd like to cover is an object for DefenseDesignDocument, and
collective objects where necessary for things that can have more than
one.
For example, it appears that <position> and <centroidPosition> are
probably representations of a single object, with methods that look
like...
getLatitude()
setLatitude(x)
getLatitudeUnits()
setLatitudeUnits(x)
[...]
etc.
Which is, indeed, one way to do it, using location="xxx" to define
the xpath in the document you want to create/store this stuff in, and
using lots of get-method/set-method pairs to ensure you map units="x"
to getLatitudeUnits or getLongitudeUnits, etc.
That's the quick-and-dirty two-object solution, involving a manual
mapping; but it also depends on whether you want, for example,
multiple locations - which will infer a container object you'll want
to instantiate - or for that matter, whether shapes have multiple
polygons, etc.
Personally?
I spend my time trying to think about how the business objects need
to behave; then I try to find a way to map Castor to the business
objects behavior, avoiding code generation and building up classes
that directly represent the way the application needs to access and
use the information. Castor API is then added to an object only when
there is no way to get Castor to map to the existing business API, or
when a mechanism needs to be provided for Castor to access something
I don't want to be considered a part of the public API for the
business-level object.
This avoids situations where I feel I need to create value objects,
which are created from the business object and then discarded after
the Castor operation, which does nothing but add lots of pointless
code and churn through memory in large-volume operations, and forces
me to think about the way the information will be used.
As a result, you'll end up doing a lot of manual mapping - but the
objects you end up with will be generally useful, and not something
you end up having to scrape your information out of to be useful to you.
<MDADocument>
<defenseDesignDocument>
<location type="absolute"> -
does this need to be a new class
<centroidPosition>
<latitude units="degrees">36.1902</
latitude> - do each of these need to be classes (what is
throwing me off is the
<longitude units="degrees">47.424</
longitude> fact that it is the "latitude units" and then the
degree amount)
</centroidPosition>
<shape>
<polygon>
<points>
<position>
<latitude
units="degrees">36.157</latitude> -how would the
mapping file look based on these?
<longitude
units="degrees">47.1334</longitude>
<sequenceNumber>1</
sequenceNumber> -I'm used to seeing the fields like
this line, not the lat/lon fields
</position>
<position>
<latitude
units="degrees">35.8809</latitude>
<longitude
units="degrees">47.3325</longitude>
<sequenceNumber>2</
sequenceNumber>
</position>
<position>
<latitude
units="degrees">35.5345</latitude>
<longitude
units="degrees">47.7023</longitude>
<sequenceNumber>3</
sequenceNumber>
</position>
</points>
</polygon>
</shape>
</location>
</defenseDesignDocument>
</MDADocument>
If this is too vague, then let me know and I will try to elaborate.
Thanks,
Jason
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
