Craig, I agree and like yourself I want those proxies very much. My comment was more on the implementation side: what benefits would the dynamic proxy API bring.... For example I start to imagine one: the possibility to write one ProxyDynaBean implementation which can work with different InvocationHandler in order to implement: - proxy from an existing bean - proxy from a result set - proxy from a prepared statement (useful for the setter methods) - proxy with read-only feature
Not sure if all the examples above really make sense, I'm only trying to be creative here... Fr. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 28 December 2001 17:12 To: Jakarta Commons Developers List Subject: RE: [Design Discussion] DynaBeans - Dynamic Proxy On Fri, 28 Dec 2001, Rey Francois wrote: > Date: Fri, 28 Dec 2001 16:46:22 +0100 > From: Rey Francois <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: 'Jakarta Commons Developers List' <[EMAIL PROTECTED]> > Subject: RE: [Design Discussion] DynaBeans - Dynamic Proxy > > -----Original Message Extract----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: 25 December 2001 00:52 > To: [EMAIL PROTECTED] > Subject: [Design Discussion] DynaBeans - Round 2 > (...) > > > Proposed Next Steps (Once Design Is Agreed Upon): > > > (4) Implement "proxy" DynaClass and DynaBean wrappers around standard > JavaBeans. (This sounds sort of backwards, but allows an application > to be written *totally* in terms of DynaBeans if desired.) > > (5) Implement a convenient way to convert a java.sql.ResultSet (or RowSet) > into a series of DynaBeans, where the corresponding DynaClass is > synthesized based on the metadata of the result set. > > -----End of Original Message Extract----- > > About the two items above, I'm wondering if we cannot implement them using > the dynamic proxy API introduced in J2SE 1.3 (see > http://java.sun.com/j2se/1.3/docs/guide/reflection/proxy.html). I'm not > clear yet on what would be the benefits of such approach, as I'm just > recently discovering this API... > > Has anybody further thoughts on this? > My take is this ... once you start dealing with properties in a dynamic way, you want to be able to treat *everything* that way (from a programming API perspective) in some circumstances. In the case of DynaBeans, the programming APIs you use to retrieve a property (for example) are different than standard JavaBeans: String foo = regularBean.getFoo(); versus String foo = dynaBean.get("foo"); which can be pretty annoying. Sometimes, I'd like to be able to program everything as if it's a DynaBean, even if it is a standard JavaBean underneath. A proxy DynaBean class that simply wraps standard JavaBeans in the DynaBean APIs lets you hve this luxury. ProxyDynaBean dynaBean = new ProxyDynaBean(regularBean); String foo = dynaBean.get("foo"); > Fr. Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> ************************************************************************ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *********************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
