xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
Subject Re: [bea-readme] design feature requests
Date Sun, 10 Aug 2003 13:49:57 GMT
On Friday, August 8, 2003, at 09:47 AM, Steve Maring wrote:


> > "At all cost" is a stronger statement than we make.  The constructor
> > requirement you propose in particular is attractive, yet fairly
> > constraining, because of the penalties you need to accept.  By tying
> > yourself to a single public implementation class, you rule out (1)
> > allowing a framework to provide multiple different implementations
> > (e.g., fast versus high-fidelity versus change-tracking); you rule
> > out (2) allowing sophisticated users to wrap your classes with their
> > own implementations; and you rule out (3) use of other powerful
> > techniques like dynamic proxies as interceptors.  I agree it would
> > be desirable to say "new Foo()", but "Foo.Factory.newInstance()" is
> > not too bad, and the difference in convenience needs to be weighed
> > against the other penalties.
> Well then maybe it should be a configurable option, set in the binding/
> mapping file, for source code generation and mapping purposes.  I can
> imagine a use case where my XML Schemas and subsequent Java data types
> are branded "The Enterprise Model".  If my Java data types are not
> simple JavaBeans, then my junior developers trying to code web services
> are always going to have to plug in the (un)marshalling framework into
> the web services implementation (currently non-trivial in most cases).
> This because the default BeanSerializer EXPECTS that any non-primitive
> Java data types coming along are in fact REAL JavaBeans with public
> default constructors!

one possible design would be to use a real java bean (or at least an 
object ;) to specify the mapping (rather than a file).

one implementation might configure itself from an input source but other 
implementations could be generated from an input source. users could even 
create their own subclasses.

- robert

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

View raw message