Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 53272 invoked from network); 15 Dec 2001 23:30:13 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Dec 2001 23:30:13 -0000 Received: (qmail 19987 invoked by uid 97); 15 Dec 2001 23:30:16 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 19971 invoked by uid 97); 15 Dec 2001 23:30:16 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 19960 invoked from network); 15 Dec 2001 23:30:15 -0000 From: "Vincent Massol" To: "'Jakarta Commons Developers List'" Subject: RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties Date: Sat, 15 Dec 2001 23:27:33 -0000 Organization: OCTO Technology Message-ID: <002d01c185c0$16398d10$0300a8c0@octovma> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20011215124744.H63471-100000@localhost> Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N +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: unsubscribe@jakarta.apache.org> > For additional commands, e-mail: help@jakarta.apache.org> > -- To unsubscribe, e-mail: For additional commands, e-mail: