> for B i'll be interested to see what others have to say. it might be
> worth monitoring responses to the recent post about polymorphism also,
> in relation to B.
Me too. Although reuse via (complexType) inheritance (bound to a hierarchy of java interfaces) is the most intuitive for me, I am also open to reuse via (group) composition. It appears, however, that the Java classes generated from groups are not reusable in the same way that their XML corrolaries are. .. I am, of course, still very interested in any comments on my earlier post...
- Matt
-----Original Message-----
From: dev_at_samizdatdigital.org [mailto:dev_at_samizdatdigital.org]
Sent: Mon 6/28/2004 3:22 PM
To: users_at_jaxb.dev.java.net
Cc:
Subject: Re: avoiding anonymous complex types to generate fewer classes?
as for part A, i personally like to follow those conventions. may be a
slight repeat of the article, but:
1) anonymous types correspond to inner types. this can make for some
weird and difficult to maintain code, as well as some strange
constructs (you end up passing around inner types of some object to
methods and setters of another).
2) see 3
3) i've gotten into the habit of defining complex type FooType and
then having the root of my schema be <xsd:element name="Foo"
type="FooType"/>. this makes for a clear distinction between something
which marshals as <Foo>...</Foo> (the element) and something which
marshals as a bunch of stuff floating around with no enclosing tag (the
complex type). the latter is good for including elsewhere, though, so
it gets used. the "Type" distinction is also nice for enabling reuse.
if i have PhoneType, i can create elements 'Cellphone', 'HomePhone',
and 'Fax', all of type 'PhoneType' (maybe some regex or something), and
it makes sense, both in the marshalled code and in the api which xjc
generates. if you try to have CellPhone or HomePhone be a ref to a
Phone element instead of an instance of the complex type PhoneType, you
can't do anything interesting to differentiate or extend them (maybe
the cell and home have an 'hours to call' attribute as well, or
something).
the pattern friends and i have begun to adopt is : complex types ==
classes, elements = instantiations of those classes. for clarity, name
types FooType.
for B i'll be interested to see what others have to say. it might be
worth monitoring responses to the recent post about polymorphism also,
in relation to B.
jon
On Jun 28, 2004, at 11:25 AM, Andrew Ferguson wrote:
> hi,
>
> A)
> this article:
> http://www.onjava.com/pub/a/onjava/2003/12/10/jaxb.html
>
> advocates the practicse below to generate fewer classes (ie
> because none are generated for anonymous types)
> 1) not using anonymous complex types
> 2) not using ref's
> 3) naming your complex types and elements that use them with
> the same identifier
>
> Is this recommended? There is also this article
> http://www.kohsuke.org/xmlschema/
> XMLSchemaDOsAndDONTs.html#avoid_complex
>
> which advocates using anonymous complex types (ie the opposite to
> point 1 above)
>
> B) the DOsAndDONTs article also says that restricting complexTypes
> isn't recommended because validators may not truly check the
> restrictions hold (sorry if i have misread this..)
>
> I've recently been wanting to use restriction because the classes xjc
> generates would then be amenable to routines that could process the
> base classes and only do more specific processing if needed - does
> this sound reasonable?
>
> (i've checked that the validater catches the more general content in
> the restricted instance and it does seem to work?)
>
> thanks,
> Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net