[
https://issues.apache.org/jira/browse/TAPESTRY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Zeigler updated TAPESTRY-2592:
-------------------------------------
Attachment: TAPESTRY-2592.2.patch
2nd patch, which adds three files necessary for the integration test.
> BeanEditor should provide a "BeanEditContext" into the environment. (or
> PropertyEditContext should include the bean class).
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2592
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2592
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.14
> Environment: any
> Reporter: Robert Zeigler
> Assignee: Kevin Menard
> Fix For: 5.0.15
>
> Attachments: TAPESTRY-2592.2.patch, TAPESTRY-2592.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
