> 1. Clazz APIs and three implementations of those: > a) Standard JavaBeans clazz loader. Recognizes properties the way > java.beans.Introspector does, including the indexed ones. > b) Extended Bean clazz loader. In addition to the functionality of the > Standard loader, also > - recognizes plural form of a property (getCustomer, > getCustomerList, etc) > - recognizes list (indexed) and mapped properties > - for the list and mapped properties recognizes a number of > additional accessors a la "addCustomer", "removeCustomer", > "getCustomerCount" etc. > - provides implementations of the List and Map interfaces that are > backed by accessor methods. > c) Mutable BeanClazz, which allows you to create Clazzes and their > instances dynamically. Time has constrained me from looking in detail, but this covers the basic goals for clazz properties well ;-)
> 2. Clazz has a new kind of feature - InstanceFactory. In the most basic > case an InstanceFactory is an reflected constructor. In addition to the > basic case, we also recognize as a factory a static method returning an > instance of the target class. I was thinking that this generalization would > play quite well with EJBs, which have separate factory methods on the Home. > All these variations would be transparent to the client. +1 > 3. There is a change notification mechanism. Register a ClazzChangeListener > with a Clazz and you will get notifications when the clazz changes: a > property, operation or factory is added or removed. +1 > 1. Attributes. There is a placeholder method on ClazzElement: > getAttribute(String name), however it is currently unimplemented. I think > we need to better understand our relationship with the [attribute] project > before we finalize these APIs. I see [clazz] depending on [attributes] for the implementation of attributes. However, [clazz] users might also want to implement their own attribute mechanism independent of [attributes], so a light conversion layer of some kind is probably needed. > 2. Delegators. If my understanding of Delegators is correct, we need a > method like this: > > clazz.addDeclaredOperation(ClazzOperation delegator) > > These delegators will be seen as regular, method-based operations by the > client. Is this correct? Is there more to them? Do they need to be > designated as "delegators"? A ClazzOperation in reflection terms is a Method object, however it might alternatively be implemented as a Jelly script or Velocity transformation or .... Basically anywhere where there is processing. eg. clazzOp.invoke(object, params) An Operation is the delegate. It is the ClazzOperation, plus a reference to the bean itself. eg. op.invoke(params) > 3. Interfaces. I am not sure what the use case would be for interfaces in > the Clazz world (I guess they would have to be called "interfazes". We can > always inquire like this: > > MyInteface.class.isAssignableFrom(clazz.getInstanceClass()) > > Does this address the requirement or we need actual Interfaze metadata for > something? I would avoid interfaces for the moment. We don't have a use case, and they add complexity. If [clazz] succeeds then we can add them later. > 4. Exception declarations on operations. Once again, I am not sure what the > purpose of that would be. When you call clazzOperation.invoke(...), it may > throw a RuntimeException, which can be examined dynamically, but I am not > convinced we need any metadata on it. Agreed, extra metadata here is not useful. > 5. Modifiers. Currently, everything introspected is based on public methods > of the target class. What are some use cases for modifiers on > ClazzProperties and ClazzOperations? In the Joda system, private methods can be introspected as this allows tools like XML readers to set values, but not ordinary program code. This doesn't require that ClazzProperties and ClazzOperations themselves have modifiers. We are trying to enable access to the properties/operations, not provide information on things that aren't accessible. One thing we need to be careful of is performance. As I have found at work, an object model that creates too many objects will scale badly. But we should optimise once the basic design is right and working. Premature optimisation is Bad ;-) Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
