[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    Re: [bea-readme] design feature requests
From:       robert burrell donkin <rdonkin () apache ! org>
Date:       2003-08-10 13:49:57
[Download RAW message or body]

On Friday, August 8, 2003, at 09:47 AM, Steve Maring wrote:

<snip>

> > "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


[prev in list] [next in list] [prev in thread] [next in thread]