aappddeevv <[email protected]> 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:[email protected]]
Sent: Wednesday, June 09, 2010 10:56 AM
To: [email protected]
Cc: [email protected]
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
