You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2010/06/09 01:41:38 UTC
Re: Component names inside the containers
Hi Dirk,
After thinking this through a bit, I am starting to think that your idea to use an annotation here might make sense. I believe you suggested something along the lines of:
@IDProperty(name="foo")
If this attribute is specified, WTKXSerializer would propagate the ID value to the given property. This would avoid the name duplication and would be a fairly trivial change. I'm still not convinced that it is absolutely necessary, but it is nice to have and obviously has some use cases. Also, I believe Spring offers a similar feature via the BeanNameAware interface, so it would be nice to have a comparable feature.
G
On Jun 8, 2010, at 6:03 PM, Dirk Möbius wrote:
> Greg Brown wrote:
>> We don't actually need an annotation for this. Simply adding the getter and setter is sufficient to support the "name" attribute.
>
> Oh, I thought the wtkx:id should be used as the name. So that you don't have to set an id AND a name:
>
> <PushButton wktx:id="myButton"/>
>
> looks better than:
>
> <PushButton wktx:id="myButton" name="myButton"/>
>
> I thought it would have been considered as a general good thing to have the wtkx:id injected into any object instance (of any type, in case it's annotated).
>
> Dirk.
Re: IDE questions (was "Component names inside the containers")
Posted by Greg Brown <gk...@mac.com>.
The tutorial is probably the best place to start:
http://pivot.apache.org/tutorials/
The Javadoc will probably also be helpful, as will the demos and their associated source code (some of which lives in the tutorials and tools projects):
http://pivot.apache.org/1.5/docs/api/
http://pivot.apache.org/demos/
http://svn.apache.org/repos/asf/pivot/trunk/demos/
http://svn.apache.org/repos/asf/pivot/trunk/tutorials/
http://svn.apache.org/repos/asf/pivot/trunk/tools/
On Jun 9, 2010, at 5:18 PM, Pedro wrote:
> Greg, documents info about Pivot are... class doc's (html)., tutorials ? Any book or brochure ?
>
> Tank's
>
> Pedro
> --------------------------------------------------
> From: "Greg Brown" <gk...@mac.com>
> Sent: Wednesday, June 09, 2010 4:49 PM
> To: <us...@pivot.apache.org>
> Subject: Re: IDE questions (was "Component names inside the containers")
>
>>> 1 - Eclipse o NetBeans for develop...
>>
>> Either is fine. You can also develop using command line tools if you prefer.
>>
>>> 2 - Any plugin ( there are one for Eclipse) ?
>>
>> No, but you don't really need one. You just need to add the Pivot JARs to your project's classpath.
>>
Re: IDE questions (was "Component names inside the containers")
Posted by Pedro <pe...@hotmail.com>.
Greg, documents info about Pivot are... class doc's (html)., tutorials ? Any
book or brochure ?
Tank's
Pedro
--------------------------------------------------
From: "Greg Brown" <gk...@mac.com>
Sent: Wednesday, June 09, 2010 4:49 PM
To: <us...@pivot.apache.org>
Subject: Re: IDE questions (was "Component names inside the containers")
>> 1 - Eclipse o NetBeans for develop...
>
> Either is fine. You can also develop using command line tools if you
> prefer.
>
>> 2 - Any plugin ( there are one for Eclipse) ?
>
> No, but you don't really need one. You just need to add the Pivot JARs to
> your project's classpath.
>
>
Re: IDE questions (was "Component names inside the containers")
Posted by Greg Brown <gk...@mac.com>.
> 1 - Eclipse o NetBeans for develop...
Either is fine. You can also develop using command line tools if you prefer.
> 2 - Any plugin ( there are one for Eclipse) ?
No, but you don't really need one. You just need to add the Pivot JARs to your project's classpath.
Re: Component names inside the containers
Posted by Pedro <pe...@hotmail.com>.
Hi, I'm new to Pivot, is a interesting framework.
My questions...
1 - Eclipse o NetBeans for develop...
2 - Any plugin ( there are one for Eclipse) ?
Tank's in advance
Pedro
--------------------------------------------------
From: "Greg Brown" <gk...@mac.com>
Sent: Wednesday, June 09, 2010 4:30 PM
To: <us...@pivot.apache.org>
Subject: Re: Component names inside the containers
>> Yes, annotate IDProperty with @Inherited.
>> You don't need a static findAnnotation() method.
>
> Nice. Thanks.
>
>
Re: Component names inside the containers
Posted by Greg Brown <gk...@mac.com>.
> Yes, annotate IDProperty with @Inherited.
> You don't need a static findAnnotation() method.
Nice. Thanks.
Re: Component names inside the containers
Posted by Dirk Möbius <dm...@scoop-gmbh.de>.
Greg Brown wrote:
> I actually started prototyping this last night. I ran into what appears to be a bug in Class#getAnnotation(), but I'm not sure. The Javadoc for this method isn't specific, but the Javadoc for getDeclaredAnnotations() implies that getAnnotation() and getAnnotations() will traverse the class hierarchy looking for annotations, but getDeclaredAnnotations() will not. However, I have not found that to be the case in practice. I can walk up the class hierarchy myself, but I'm wondering if I'm simply misunderstanding something. Any ideas?
Yes, annotate IDProperty with @Inherited.
You don't need a static findAnnotation() method.
Dirk.
> On Jun 9, 2010, at 4:08 AM, Dirk Möbius wrote:
>
>> Greg Brown <gk...@mac.com> wrote:
>>> After thinking this through a bit, I am starting to think that your idea to use an annotation here might make sense. I believe you suggested something along the lines of:
>>>
>>> @IDProperty(name="foo")
>> Yes, or simply @Id, or @WtkxId to make clear that the wtkx:id gets injected.
>> @BxId also comes to mind, because you announced that WtkxSerializer will be renamed to BeanSerializer.
>>
>> Note that if you use "value" as annotation parameter, you can omit it in the usage:
>>
>> @IDProperty("foo")
>>
>> You could also set the value "id" as default:
>>
>> public interface @Id {
>> String value() = "id";
>> }
>>
>> Thus, you only need to annotate a class with
>>
>> @Id
>> public class Component {
>> ...
>> }
>>
>> and it is assumed to have a getId()/setId() pair.
>>
>> Btw. my previous post about this is here (dated 05/07):
>> http://mail-archives.apache.org/mod_mbox/pivot-user/201005.mbox/%3C20100507092329.13532v1k8xha1bsw@www.premium-webmail.de%3E
>>
>>> If this attribute is specified, WTKXSerializer would propagate the ID value to the given property. This would avoid the name duplication and would be a fairly trivial change. I'm still not convinced that it is absolutely necessary, but it is nice to have and obviously has some use cases. Also, I believe Spring offers a similar feature via the BeanNameAware interface, so it would be nice to have a comparable feature.
>> Yes, it's like BeanNameAware, but annotations are less invasive because they don't prescribe a certain method name.
>>
>> Dirk.
RE: Component names inside the containers
Posted by aappddeevv <aa...@verizon.net>.
I'm not hard and fast on the annotation, just mindful of tree traversal.
When I wrote a tree walker with the presence of the default property it
makes it harder so I was thinking to not make it harder when walking the
tree by id/name. That's as deep as my thinking was which is not too deep.
Yes, it is the same problem with the default property. I was trying to avoid
the same problem again. One might think about fast failing in both default
properties and id property specifications.
We'll probably want to write a tree walker utils method to correctly walk
trees by id or by object.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com]
Sent: Thursday, June 10, 2010 10:24 AM
To: user@pivot.apache.org
Subject: Re: Component names inside the containers
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.
G
On Jun 10, 2010, at 3:29 AM, Dirk Möbius wrote:
> aappddeevv <aa...@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
>
>
Re: Component names inside the containers
Posted by Greg Brown <gk...@mac.com>.
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.
G
On Jun 10, 2010, at 3:29 AM, Dirk Möbius wrote:
> aappddeevv <aa...@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
>
>
RE: Component names inside the containers
Posted by aappddeevv <aa...@verizon.net>.
I provided a couple of thoughts below with [[[
-----Original Message-----
From: Dirk Möbius [mailto:dmoebius@scoop-gmbh.de]
Sent: Thursday, June 10, 2010 3:30 AM
To: user@pivot.apache.org
Subject: RE: Component names inside the containers
aappddeevv <aa...@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.
[[[[Yes, however using the name property has no interface either. But I get
your point.
> 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?
[[[I hear you on this. In fact, you can consider the serializer to almost be
a DI-container, however, its not. I can send you my spring serializer
extension
that allows all objects in the serializer to participate in full DI creation
and initialization semantics if you want. That was the point of doing a very
small change request to the serializer.
This allows me, while not making the serializer significantly different,
to automatically create a spring application context based off the pivot
component class name, use full DI semantics to initialize the pivot
component
and then start it doing "something" as its added back into the component
tree. You could use the serializer extension to also have finalization
semantics implemented but I had not thought about object lifecycle enough
yet.
In the case of the serializer and creation and initialization semantics,
we'll probably have to define a few well thought-out APIs that allow
stronger contracts and more communication between components for creation,
initialization, tree construction and tree deconstruction.
For example, I can easily create a full style defaulting system if I can
just receive a notification about component adds/removes across the
component tree (and not just across the superclass tree).
> 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.
[[[I've noticed that about your recommendations. I think you have
alot of good ideas and I believe your intent is all in the right
direction. I myself think that solid engineering backing simplistic
API makes pivot a huge winner. That's why I always push for
the strategy design pattern to be used, for extensibility without
subclasses, etc. All this makes for solid engineering that
allows API creation that is simplistic for people like me.
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.
[[[I would not frame it as annotation versus BeanNameAware. I think
That with using "name", there is no interface as well. But I get your
point and I am not hard and fast on it as long as we can write
a tree walker and make it easier for everyone to walk by id. Which,
with a pivot official "tree walker by id" utils method, works fine
for me.
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
RE: Component names inside the containers
Posted by Dirk Möbius <dm...@scoop-gmbh.de>.
aappddeevv <aa...@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
RE: Component names inside the containers
Posted by aappddeevv <aa...@verizon.net>.
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: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
RE: Component names inside the containers
Posted by aappddeevv <aa...@verizon.net>.
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: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
Re: Component names inside the containers
Posted by Greg Brown <gk...@mac.com>.
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
Re: Component names inside the containers
Posted by Greg Brown <gk...@mac.com>.
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
RE: Component names inside the containers
Posted by aappddeevv <aa...@verizon.net>.
It does not traverse or at least I ran into the same issue. Never could
figure out what should really happen.
If you look at the patch I submitted for the @DefaultProperty issue, I had
to traverse to find the default property, which is often 1 or 2 levels up
from the subclass that the client implements.
It may be time to create yet another AnnotationUtils static helper class.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com]
Sent: Wednesday, June 09, 2010 10:23 AM
To: user@pivot.apache.org
Subject: Re: Component names inside the containers
I actually started prototyping this last night. I ran into what appears to
be a bug in Class#getAnnotation(), but I'm not sure. The Javadoc for this
method isn't specific, but the Javadoc for getDeclaredAnnotations() implies
that getAnnotation() and getAnnotations() will traverse the class hierarchy
looking for annotations, but getDeclaredAnnotations() will not. However, I
have not found that to be the case in practice. I can walk up the class
hierarchy myself, but I'm wondering if I'm simply misunderstanding
something. Any ideas?
On Jun 9, 2010, at 4:08 AM, Dirk Möbius wrote:
> Greg Brown <gk...@mac.com> wrote:
>> After thinking this through a bit, I am starting to think that your idea
to use an annotation here might make sense. I believe you suggested
something along the lines of:
>>
>> @IDProperty(name="foo")
>
> Yes, or simply @Id, or @WtkxId to make clear that the wtkx:id gets
injected.
> @BxId also comes to mind, because you announced that WtkxSerializer will
be renamed to BeanSerializer.
>
> Note that if you use "value" as annotation parameter, you can omit it in
the usage:
>
> @IDProperty("foo")
>
> You could also set the value "id" as default:
>
> public interface @Id {
> String value() = "id";
> }
>
> Thus, you only need to annotate a class with
>
> @Id
> public class Component {
> ...
> }
>
> and it is assumed to have a getId()/setId() pair.
>
> Btw. my previous post about this is here (dated 05/07):
>
http://mail-archives.apache.org/mod_mbox/pivot-user/201005.mbox/%3C201005070
92329.13532v1k8xha1bsw@www.premium-webmail.de%3E
>
>> If this attribute is specified, WTKXSerializer would propagate the ID
value to the given property. This would avoid the name duplication and would
be a fairly trivial change. I'm still not convinced that it is absolutely
necessary, but it is nice to have and obviously has some use cases. Also, I
believe Spring offers a similar feature via the BeanNameAware interface, so
it would be nice to have a comparable feature.
>
> Yes, it's like BeanNameAware, but annotations are less invasive because
they don't prescribe a certain method name.
>
> Dirk.
>
>>
>> G
>>
>> On Jun 8, 2010, at 6:03 PM, Dirk Möbius wrote:
>>
>>> Greg Brown wrote:
>>>> We don't actually need an annotation for this. Simply adding the getter
and setter is sufficient to support the "name" attribute.
>>>
>>> Oh, I thought the wtkx:id should be used as the name. So that you don't
have to set an id AND a name:
>>>
>>> <PushButton wktx:id="myButton"/>
>>>
>>> looks better than:
>>>
>>> <PushButton wktx:id="myButton" name="myButton"/>
>>>
>>> I thought it would have been considered as a general good thing to have
the wtkx:id injected into any object instance (of any type, in case it's
annotated).
>>>
>>> Dirk.
>>
>>
>
>
>
> --
> Dirk Möbius
>
> SCOOP GmbH
> Am Kielshof 29
> D-51105 Köln
> Fon +49 221 801916-0
> Fax +49 221 801916-17
> Mobil +49 170 7363035
> www.scoop-gmbh.de
> Sitz der Gesellschaft: Köln
> Handelsregister: Köln
> Handelsregisternummer: HRB 36623
> Geschäftsführer:
> Dr. Oleg Balovnev
> Frank Heinen
> Dr. Wolfgang Reddig
> Roland Scheel
>
>
Re: Component names inside the containers
Posted by Greg Brown <gk...@mac.com>.
I actually started prototyping this last night. I ran into what appears to be a bug in Class#getAnnotation(), but I'm not sure. The Javadoc for this method isn't specific, but the Javadoc for getDeclaredAnnotations() implies that getAnnotation() and getAnnotations() will traverse the class hierarchy looking for annotations, but getDeclaredAnnotations() will not. However, I have not found that to be the case in practice. I can walk up the class hierarchy myself, but I'm wondering if I'm simply misunderstanding something. Any ideas?
On Jun 9, 2010, at 4:08 AM, Dirk Möbius wrote:
> Greg Brown <gk...@mac.com> wrote:
>> After thinking this through a bit, I am starting to think that your idea to use an annotation here might make sense. I believe you suggested something along the lines of:
>>
>> @IDProperty(name="foo")
>
> Yes, or simply @Id, or @WtkxId to make clear that the wtkx:id gets injected.
> @BxId also comes to mind, because you announced that WtkxSerializer will be renamed to BeanSerializer.
>
> Note that if you use "value" as annotation parameter, you can omit it in the usage:
>
> @IDProperty("foo")
>
> You could also set the value "id" as default:
>
> public interface @Id {
> String value() = "id";
> }
>
> Thus, you only need to annotate a class with
>
> @Id
> public class Component {
> ...
> }
>
> and it is assumed to have a getId()/setId() pair.
>
> Btw. my previous post about this is here (dated 05/07):
> http://mail-archives.apache.org/mod_mbox/pivot-user/201005.mbox/%3C20100507092329.13532v1k8xha1bsw@www.premium-webmail.de%3E
>
>> If this attribute is specified, WTKXSerializer would propagate the ID value to the given property. This would avoid the name duplication and would be a fairly trivial change. I'm still not convinced that it is absolutely necessary, but it is nice to have and obviously has some use cases. Also, I believe Spring offers a similar feature via the BeanNameAware interface, so it would be nice to have a comparable feature.
>
> Yes, it's like BeanNameAware, but annotations are less invasive because they don't prescribe a certain method name.
>
> Dirk.
>
>>
>> G
>>
>> On Jun 8, 2010, at 6:03 PM, Dirk Möbius wrote:
>>
>>> Greg Brown wrote:
>>>> We don't actually need an annotation for this. Simply adding the getter and setter is sufficient to support the "name" attribute.
>>>
>>> Oh, I thought the wtkx:id should be used as the name. So that you don't have to set an id AND a name:
>>>
>>> <PushButton wktx:id="myButton"/>
>>>
>>> looks better than:
>>>
>>> <PushButton wktx:id="myButton" name="myButton"/>
>>>
>>> I thought it would have been considered as a general good thing to have the wtkx:id injected into any object instance (of any type, in case it's annotated).
>>>
>>> Dirk.
>>
>>
>
>
>
> --
> Dirk Möbius
>
> SCOOP GmbH
> Am Kielshof 29
> D-51105 Köln
> Fon +49 221 801916-0
> Fax +49 221 801916-17
> Mobil +49 170 7363035
> www.scoop-gmbh.de
> Sitz der Gesellschaft: Köln
> Handelsregister: Köln
> Handelsregisternummer: HRB 36623
> Geschäftsführer:
> Dr. Oleg Balovnev
> Frank Heinen
> Dr. Wolfgang Reddig
> Roland Scheel
>
>
Re: Component names inside the containers
Posted by Dirk Möbius <dm...@scoop-gmbh.de>.
Greg Brown <gk...@mac.com> wrote:
> After thinking this through a bit, I am starting to think that your
> idea to use an annotation here might make sense. I believe you
> suggested something along the lines of:
>
> @IDProperty(name="foo")
Yes, or simply @Id, or @WtkxId to make clear that the wtkx:id gets injected.
@BxId also comes to mind, because you announced that WtkxSerializer
will be renamed to BeanSerializer.
Note that if you use "value" as annotation parameter, you can omit it
in the usage:
@IDProperty("foo")
You could also set the value "id" as default:
public interface @Id {
String value() = "id";
}
Thus, you only need to annotate a class with
@Id
public class Component {
...
}
and it is assumed to have a getId()/setId() pair.
Btw. my previous post about this is here (dated 05/07):
http://mail-archives.apache.org/mod_mbox/pivot-user/201005.mbox/%3C20100507092329.13532v1k8xha1bsw@www.premium-webmail.de%3E
> If this attribute is specified, WTKXSerializer would propagate the
> ID value to the given property. This would avoid the name
> duplication and would be a fairly trivial change. I'm still not
> convinced that it is absolutely necessary, but it is nice to have
> and obviously has some use cases. Also, I believe Spring offers a
> similar feature via the BeanNameAware interface, so it would be nice
> to have a comparable feature.
Yes, it's like BeanNameAware, but annotations are less invasive
because they don't prescribe a certain method name.
Dirk.
>
> G
>
> On Jun 8, 2010, at 6:03 PM, Dirk Möbius wrote:
>
>> Greg Brown wrote:
>>> We don't actually need an annotation for this. Simply adding the
>>> getter and setter is sufficient to support the "name" attribute.
>>
>> Oh, I thought the wtkx:id should be used as the name. So that you
>> don't have to set an id AND a name:
>>
>> <PushButton wktx:id="myButton"/>
>>
>> looks better than:
>>
>> <PushButton wktx:id="myButton" name="myButton"/>
>>
>> I thought it would have been considered as a general good thing to
>> have the wtkx:id injected into any object instance (of any type, in
>> case it's annotated).
>>
>> Dirk.
>
>
--
Dirk Möbius
SCOOP GmbH
Am Kielshof 29
D-51105 Köln
Fon +49 221 801916-0
Fax +49 221 801916-17
Mobil +49 170 7363035
www.scoop-gmbh.de
Sitz der Gesellschaft: Köln
Handelsregister: Köln
Handelsregisternummer: HRB 36623
Geschäftsführer:
Dr. Oleg Balovnev
Frank Heinen
Dr. Wolfgang Reddig
Roland Scheel