Please check out the two attached classes: Clazz and Field. These are client APIs only. Nothing is said about where the metadata is coming from - that's to come later.
Here are some notes on the design of these two classes: 1. Clazz is a metadescription of a generalized bean (JDK bean, "modern" bean, DynaBean, Map, EJB etc). 2. In some cases there is more than one Clazz that can describe a particular object. For example, the same object can be described as a standard bean as well as a "modern" bean. Therefore I have introduced the notion of a "model" identified by a URI. I am thinking the URI itself might map to a verbal description of the model. 3. Clazz has a newInstance() method that is responsible for object allocation. 4. You do not get a list of Field objects from a Clazz. Instead, you get a list of field names and then can acquire a Field object for an individual field. The reason is that allocation of Field objects may involve multiple plugins and therefore be costly. Also, in the case of a Map, we would effectively be recreating the map with the Field objects. 5. Field hides the mechanisms of actual value extraction/manipulation. You don't get any "readMethods", "writeMethods" etc. You simply delegate the value manipulations to the Field object. 6. Field is scalar, indexed and mapped at the same time and has all corresponding APIs. If you use the wrong APIs on a field, it will just throw an exception. 7. There are attributes associated with a Clazz and Field. Does any of this make sense? - Dmitri
Field.java
Description: Binary data
Clazz.java
Description: Binary data
-- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
