commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Date Mon, 17 Dec 2001 20:46:45 GMT


On Mon, 17 Dec 2001, Scott Sanders wrote:

> Date: Mon, 17 Dec 2001 10:27:24 -0800
> From: Scott Sanders <ssanders@nextance.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>,
>      ssanders@nextance.com
> To: 'Jakarta Commons Developers List' <commons-dev@jakarta.apache.org>
> Subject: RE: [Design Discussion] DynaBean - JavaBeans with dynamic
>     properties
>
> Craig, +1 from me.
>
> Although I do believe in stringly typed systems, I also find a need for
> something 'Pythonesque' in my web applications.  This would fit the bill
> excellently.

I agree ... I will be incorporating the excellent feedback over the
weekend into an updated proposal in the next couple of days.

>  We could also get these things to be compilable for
> performance, no?

Well, you could conceive of generating a JavaBean class that has all the
right properties, but then you give up the ability to dynamically adjust
them on the fly ...

In 1.4, the performance gap between direct and reflected calls has been
reduced significantly if you cache the actual Method instances (BeanUtils
doesn't do this yet, but will soon).  It's getting to the point where
performance shouldn't have to dominate the decision making process any
more -- we can base it on what makes for the most maintainable and
reliable code instead.

>
> If you then have a framework that uses DynaBean as the value object, the
> back end could be raw JDBC, EJB, XML, or ???  Without even knowing it...
>

Only the conversion layer between the value object and the underlying bean
would have to know.

> I think it is an excellent idea, let's get started.
>
> Scott Sanders
>

Craig


> > -----Original Message-----
> > From: craigmcc@localhost [mailto:craigmcc@localhost] On
> > Behalf Of Craig R. McClanahan
> > Sent: Saturday, December 15, 2001 1:26 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: [Design Discussion] DynaBean - JavaBeans with
> > dynamic properties
> >
> >
> > There's been a lot of interest, both here (COMMONS-DEV), on
> > the Struts mailing lists, and elsewhere in the idea of a
> > JavaBean-like thing where the set of properties can be
> > dynamically defined.  If support for this was integrated into
> > the BeanUtils package in Commons, we could also make the
> > methods in BeanUtils and PropertyUtils treat the properties
> > of these beans like they do for regular JavaBeans, and thus
> > be able to leverage them in environments based on BeanUtils
> > (such as Struts).
> >
> > The purpose of this email is to summarize a set of design
> > requirements for discussion purposes, so we can coalesce on a
> > design and then get it implemented.  For extra fun, I've
> > thrown in a very-raw idea of what the APIs might look like --
> > but I'd like to have the group's agreement before turning
> > that into code.
> >
> > Before embarking on the actual development of dynamic beans
> > support, we should also do a release of BeanUtils with the
> > current enhancements, to provide a stable starting point.
> >
> > Please let me know what you think!
> >
> >
> > BACKGROUND:
> >
> > The purpose of the DynaBean design (I'm not firmly attached
> > to the name, but kinda like it :-) is to support application
> > programming designs based on JavaBeans design patterns, but
> > where the static nature of JavaBeans themselves (i.e. the
> > fact that the set of properties is fixed at compile
> > time) is too restrictive.  Some typical use cases for such a
> > capability:
> >
> > * A bean object that represents a Row from a JDBC ResultSet
> >   (the names and types of the column properties cannot be known
> >   in advance because they are based on the SELECT statement).
> >
> > * A way to construct and use "value objects" that extract the
> >   properties of an EJB into a structure that can be utilized by a
> >   presentation tier technology such as JSP pages, without having
> >   to hand code the value object.
> >
> > * A way to capture *all* of the request parameters from a servlet
> >   request as a single object.
> >
> > * A way to dynamically represnt XML input data as a tree of
> > Java objects.
> >
> >
> > DESIGN REQUIREMENTS:
> >
> > * Support a completely arbitrary set of properties and corresponding
> >   values, with the ability to add and remove properties dynamically.
> >
> > * Support the ability to dynamically register the set of property
> >   names that are allowed, and then enforce storing only those
> >   property names.
> >
> > * Support the ability to register data types (Java classes) for each
> >   property, along with the names, with automatic type checking.
> >
> > * Support for properties with scalar types, array types, and
> >   "mapped" types (as currently supported in Beanutils).
> >
> > * Support "simple" and "indexed" property getters and setters
> >   in a style similar to standard JavaBeans.
> >
> > * Support registration of property change listeners and broadcast
> >   of property change events
> >
> > * Provide the basic DynaBean API as a Java interface, as well as a
> >   convenience base class, so that applications can adopt it however
> >   they wish.
> >
> > * Base implementation class should implement Serializable so that
> >   DynaBeans can be serialized and deserialized (assuming that the
> >   actual property values can be).
> >
> > * Transparently support DynaBean objects in the existing BeanUtils
> >   and PropertyUtils classes of the Bean Utilities package.
> >
> > * To the maximum extent feasible, provide JavaBeans-like introspection
> >   capabilities of the available properties.  May require an
> >   IntrospectionUtils addition to the Beanutils package.
> >
> >
> > CONCEPTUAL API:
> >
> > public interface DynaBean {
> >
> >
> >     //
> > ----------------------------------------------------------------
> >     // Dynamic property configuration
> >     //
> > ----------------------------------------------------------------
> >
> >     void addDynamic(String name);             // Unrestricted type
> >     void addDynamic(String name, Class type); // Restricted type
> >     void removeDyanamic(String name);         // Remove
> > property & value
> >     void restrictDynamic(boolean restrict);   // Are property names
> >                                               // restricted
> > to registered
> >                                               // ones?
> > (default=false)
> >                                               // (can be changed)
> >
> >     //
> > ----------------------------------------------------------------
> >     // Property getters and setters.  Behavior on previously
> >     // unknown property names depends on the restrict setting
> >     //
> > ----------------------------------------------------------------
> >
> >     // Does this bean have a property of the specified name?
> >     boolean contains(String name);
> >
> >     // Getters return null on unknown property names
> >     Object get(String name);                  // Simple
> >     Object get(String name, int index);       // Indexed
> >     Object get(String name, String key);      // Mapped
> >
> >     // Setters are allowed to set null unless property is native.
> >     // Optionally throw IllegalArgumentException if type is restricted
> >     // and the value argument is not assignment-compatible
> >     void set(String name, Object value);      // Simple
> >     void set(String name, int index,          // Indexed
> >              Object value);
> >     void set(String name, String key,         // Mapped
> >
> > }
> >
> >
> > Craig McClanahan
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message