pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: Component names inside the containers
Date Thu, 10 Jun 2010 14:23:35 GMT
I prefer the annotation. It offers more flexibility (can map WTKX ID to any property name),
and may offer slightly better performance (once obtained, annotations appear to be cached
in the class object).

The fact that the getter and setter may not actually exist for the given property is developer
error. The same issue applies to the proposed DefaultProperty annotation. This is consistent
with BeanAdapter in general, which offers no compile-time guarantees about the existence of
a property. When using BeanAdapter, it is not possible to find out until runtime if a requested
property exists or not.


On Jun 10, 2010, at 3:29 AM, Dirk Möbius wrote:

> aappddeevv <aappddeevv@verizon.net> wrote:
>> 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.
> You're right, _overriding_ the property is not useful, and although you can do that you
shouldn't do it. The annotation is for _defining_ the property without enforcing a certain
name, as you would do with an interface. See my explanation below.
>> 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.
> Note that WtkxSerializer is not only meant for creating Component trees. You can create
_any_ pojos. You can see WtkxSerializer as a configuration tool, similar to the deserialization
part of XMLBeans or SimpleXML (http://simple.sf.net). WtkxSerializer has been carefully crafted
without any references to wtk classes. In fact, the name "Wtkx" is misleading, that's why
it gets renamed to BeanSerializer and moved to another package in the next release.
> So, the fact that WtkxSerializer/BeanSerializer populates any pojo, calls for a more
flexible solution to inject the id into an arbitrary pojo. Maybe your pojo already contains
either an 'id' property or a 'name' property, why should Pivot impose the other one on it?
>> 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 see. But I think the evil doer here is the developer who overrides Component and changes
the @IdProperty annotation. I think it is sufficient to document clearly that overriding the
@IdProperty annotation is an evil thing.
> Note that WtkxSerializer would also need a setter. I admit it's a unfortunate situation
if the @IdProperty annotation is there but the setter is missing and no one enforces it. But
WtkxSerializer can fail fast in this case so the developer would notice it soon.
> I guess that by now you realized that I'm more on the pragmatic side of development --
or rather, I'm all for freedom, not for restrictions. I don't like a framework to be too restrictive
(eg. all things private/package private/protected etc.). I think we're all adults who know
what to do when we realize the intention of a framework. But that's just my personal opinion.
I make my suggestions here, but the decision is of course up to the Pivot developers. I'm
not a Pivot team member.
> That being said, I would not break down in tears if Pivot goes for the BeanNameAware
interface route. It would be a great improvement anyway if the id can be injected into the
pojos by any means.
> Regards,
> Dirk.
>> -----Original Message-----
>> From: Greg Brown [mailto:gkbrown@mac.com]
>> Sent: Wednesday, June 09, 2010 10:56 AM
>> To: dev@pivot.apache.org
>> Cc: user@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

View raw message