commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties
Date Sat, 15 Dec 2001 23:27:33 GMT
+1 for all :-)

> -----Original Message-----
> From: craigmcc@localhost [mailto:craigmcc@localhost] On Behalf Of
Craig R.
> McClanahan
> Sent: 15 December 2001 21:26
> 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>


Mime
View raw message