I took the liberty of adding jxpath to the list, because it also has an introspection mechanism. IMO, it has way too much of it and breaking it out would make tremendous sense.
When I was working on a product the current version of which is available from Object Venture, http://www.objectventure.com, I intoduced an idea in that product that was similar to yours. We called this a "Feature". A Feature (like "Attribute") was equipped with a bunch of rules that allowed it to recognize its piece parts: get, set methods and all the other stuff. That software was working with the source code parse tree, so it could see more than introspection would. The beauty of the generalization was that we could describes as Features not only attributes, but also things like business methods, finders on EJBs etc. +1 (vote of support, you don't need an actual vote to put something in sandbox) I'd like to be a contributor if you need help. - Dmitri ----- Original Message ----- From: "Juozas Baliuka" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Sunday, June 16, 2002 9:06 AM Subject: [VOTE] was Re: [BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData package > Hi, > It is good idea. I think it is no need discuss a lot. Just paste this to > PROPOSAL file > and start a new project in sandbox( or find some existing about the same). > +1 if it needs vote. > > > > Hi, > > Currently, Betwixt and other users of BeanUtils rely on the java.beans > class > > Introspector to extract details from a class. Introspector is a very old > and > > limited class in todays terms: > > - it doesn't support collections, just simple objects and arrays > > - it doesn't support modern conventions such as addXxx() adds to a the xxx > > list > > - it doesn't support overloading well > > - the bean info technique is difficult to code, poorly understood and > > limiting > > - it's just too plain dumb. > > > > I propose that BeanUtils/Betwixt/commons should replace Introspector with > a > > more general purpose reflection/introspection package. Architecturally > this > > would sit above reflection, but below Introspection: > > > > Requirements/Goals: > > - handle classes other than beans > > - support extensible metadata (not just for GUI builders) > > - handle normal (today) bean conventions (get/set/add/put methods) > > - handle future conventions that are not yet standard > > - support method overloading > > - be easily used directly from BeanUtils and Betwixt (and probably others) > > - be a complete alternative to using java.lang.reflect > > - return immutable objects > > > > My proposed solution (not coded, fully open to discussion): > > Build a system with similarities to Digester. Rules get called when the > > class is examined determine how to link the methods together. For example > > the FindGetPropertyMethodRule would look at method names starting with get > > etc. The rule then classifies the method as a GET method and stores it > into > > a structure something like this: > > > > - MethodSetInfo - holds details about a related set of methods. > > public String getName() > > public List getMethodInfos() > > public MethodInfo getMethodInfo(name) > > public Map getMetaData() > > public MetaData getMetaData(String name) > > > > - ClassInfo - main class that holds the representation of class. Subclass > of > > MethodSetInfo > > public List getMethodSetInfos() > > public MethodSetInfo getMethodSetInfo(name) > > public List getMethodSetInfos(methodSetType) > > public MethodSetInfo getMethodSetInfo(methodSetType, name) > > public PropertyInfo getPropertyInfo(name) // convenience > > > > - PropertyInfo - subclass of MethodSetInfo for properties (Lists/Maps etc. > > tbd) > > public Class getPropertyType() > > public MethodInfo getGetMethodInfo() // convenience > > public MethodInfo getSetMethodInfo() // convenience > > public Object getValue() > > public void setValue() > > > > - MethodInfo - categorised info about a method > > public String getName() > > public Method getMethod() > > publc String getCategory() > > public Map getMetaData() > > public MetaData getMetaData(String name) > > public Object invoke(object, args, respectAccessFlags) > > > > Attached to each element is the ability to hold MetaData. This is > > particularly important for Betwixt. It would allow the XMLBeanInfo class > to > > be held directly on the representation of the class. And I'm sure other > > projects want MetaData - its supposed to be a long standing request for > J2SE > > (I know I need it for the Joda project). > > > > Note that I haven't expanded on the Rule part at the moment. Basically, > > people must be able to write their own rules and add them to the standard > > rules for beans. > > > > As for which project it belongs with...I suggest lang or something new > > (reflect?). I would like to extract it from BeanUtils because its not Bean > > specific. > > > > > > Well, its an idea at the moment. There are some similarities to DynaBeans, > > but I think it goes way further. I already have a partial version of this, > > but its specific to my needs. It needs some rework anyway, so I thought > > about if it could be generic. Opinions?? > > > > Stephen > > > > PS. Three more possibilities for lang: > > Nameable > > MetaData > > Rule > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
