PropertyEditor has the useful feature of providing the PropertyEditContext to the environment. In this manner, custom blocks can be used to edit the current property and have the ability to "get" and "set" the property of the bean, display labels based on the property id, and so forth.
It can be useful, however, to have at runtime the knowledge of which bean type is being edited, or even have access to the bean under edit.
I propose a new "BeanEditContext" environment variable. The BeanEditor would push this object onto the environment. The BeanEditContext would contain, at a minimum, a "getBeanClass" method which would return the class of the current bean being edited.
An alternative solution would be to add a "getBeanClass" method to the PropertyEditContext.
Use case and discussion:
I'm currently working on a tapestry-cayenne integration module. One thing that would be nice is for the module to add all of the validation constraints for a particular property that are known to cayenne. The ideal way to handle this would be to contribute a ValidationConstraintGenerator. However, the generator's method is passed only the type of property being edited, and the annotations that were on that property. Cayenne does not require that validation constraints be specified via annotations. Hence, the integration module cannot rely on the presence of annotations to determine the validation constraints for a property type. Nor is the type of property sufficient, as it is impossible to distinguish between the validations for two different "String" by the class "String" alone. At the time of constraint generation, the PropertyEditContext is available from the environment, which helps the situation by providing the Property's name. However, the PropertyEditContext does not provide information about the bean class being edited. In order to lookup the wealth of information available from Cayenne for, eg, generating validators, I need to have this information available. As stated, this could be achieved by a BeanEditContext, or by adding "getBeanClass" to PropertyEditor.
The main issue with using a BeanEditContext is that code which relies on that environment object being available could be called without the BeanEditor having a chance to setup the context, since PropertyEditor can be used outside of BeanEditor. In practice, the PropertyEditor is rarely used outside the context of BeanEditor.
The advantage is that it is a separation of concerns: PropertyEditor doesn't care about the bean being edited. It would require no changes to the existing PropertyEditor/validator/etc. API.
Unless I receive direction otherwise, I'll be contributing a patch for this feature which implements it as a BeanEditContext environment variable.