We'll after looking this over I'm not sure that this implements my thinking although I believe that I understand Dirk's comments now. I think I saw:
a) The IDProperty annotation indicates which property the id/name should be placed into. b) The default for a Component is "name" but it could be overridden of course with the annotation on a subclass. I am not sure that overriding the property that sets the id is useful in practice. The reason why this is different than BeanNameAware is that BeanNameAware always set the property "beanName" so it always goes through the same property/setter interface. Clients then propagate the name to anywhere they want underneath which as far as I ever seen, most clients set the bean name to a property "name." If you want the equivalent of the BeanNameAware, without any extra annotations, just use the "name" property. By using the idproperty annotation, you are actually changing the property that the name is set through...very different than BeanNameAware. As for invasiveness, since the "id/name" property must be defined at the Component level, which is fairly high up in the wtx hierarchy. The invasiveness concept is less a concern than with pojo objects that have no common class hierarchy--where I would agree it is more of a concern and pojo invasiveness is more of an issue. Also, to make this useful, you need to guarantee there is a "get" property to get the id value. The idproperty annotation does not guarantee this in a subclass override--in other words, external processing operations cannot rely on being able to get the name and this makes processing ill-specified. I believe that processing external to the Component is an important use-case ie when an id is specified using the idproperty approach, you cannot guarantee that you can read the id. -----Original Message----- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Wednesday, June 09, 2010 10:56 AM To: dev@pivot.apache.org Cc: u...@pivot.apache.org Subject: Re: Component names inside the containers I have prototyped this change - see attached patch. Let me know if this is consistent with what you are envisioning. I added a static findAnnotation() method to BeanAdapter. WTKXSerializer uses this method to locate an IDProperty annotation and, if present, uses the value to set the given property. Note that we may not be able to apply this change to Pivot 1.5.1. Adding the name property requires a change to the ComponentListener interface, which would break backwards compatibility. We could potentially add the ID annotation handling to 1.5.1, though. G
