Changes look good to me, too. On Tue, Aug 19, 2008 at 6:16 PM, Kevin Menard (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/TAPESTRY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Kevin Menard closed TAPESTRY-2592. > ---------------------------------- > > Resolution: Fixed > Fix Version/s: 5.0.15 > > The patch looked good and clean. Modified a bit for code formatting. > >> 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.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] > >
-- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
