Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 44245 invoked from network); 17 Dec 2001 18:30:37 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 17 Dec 2001 18:30:37 -0000 Received: (qmail 29991 invoked by uid 97); 17 Dec 2001 18:30:38 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 29957 invoked by uid 97); 17 Dec 2001 18:30:37 -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 29946 invoked from network); 17 Dec 2001 18:30:36 -0000 Errors-To: Reply-To: From: "Scott Sanders" To: "'Jakarta Commons Developers List'" Subject: RE: [Design Discussion] DynaBean - JavaBeans with dynamic properties Date: Mon, 17 Dec 2001 10:27:24 -0800 Organization: Engineering Message-ID: <005b01c18728$7d45e9e0$6ca8a8c0@nextance.com> 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.2462.0000 Importance: Normal In-Reply-To: <20011215124744.H63471-100000@localhost> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. We could also get these things to be compilable for performance, no? 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... I think it is an excellent idea, let's get started. Scott Sanders > -----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: > unsubscribe@jakarta.apache.org> > For > additional commands, > e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: