pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "aappddeevv" <aappdde...@verizon.net>
Subject RE: Component names inside the containers
Date Fri, 11 Jun 2010 11:58:28 GMT
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 <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.

[[[[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



Mime
View raw message