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/04/19 15:34:47 UTC
WTKXSerializer -> BeanSerializer
Hi all,
I'd be very interested in any comments on this new ticket I entered this morning:
https://issues.apache.org/jira/browse/PIVOT-470
The fact that WTKXSerializer doesn't have any dependencies on WTK is almost a strong enough argument on its own to move it to pivot-core. However, I think the concept of using it to support DI and AOP is very interesting. I'd like to know what others think.
G
Re: WTKXSerializer -> BeanSerializer
Posted by Michael Allman <ms...@allman.ms>.
I'm going to retract this message indefinitely as upon further reflection
I am not fully committed to it.
Cheers,
Michael
On Fri, 2 Jul 2010, Michael Allman wrote:
> On Mon, 19 Apr 2010, Greg Brown wrote:
>
>> The fact that WTKXSerializer doesn't have any dependencies on WTK is almost
>> a strong enough argument on its own to move it to pivot-core.
>
> Maybe it should?
>
> WTKX and WTKXSerializer are very elegant in their simplicity, but they aren't
> as convenient as they could be for UI markup. And that's what WTKX is for,
> right?
>
> One thing that's been bugging me as I work on my first Pivot project is the
> verbosity of specifying styles on elements. Why can't styles be specified as
> attributes on the element in their own right? Instead of
>
> <BoxPane styles="{ backgroundColor: 'red', horizontalAlignment: 'left' }"/>
>
> how about
>
> <BoxPane backgroundColor="red" horizontalAlignment="left"/>
>
> ?
>
> The latter syntax is significantly more compact and IMHO much more readable.
> Of course, there's no reason the current syntax for settings styles couldn't
> be retained.
>
> To handle this syntax, the parser could look for a skin property matching an
> attribute name if the component itself has no such property.
>
> Cheers,
>
> Michael
>
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
>> The fact that WTKXSerializer doesn't have any dependencies on WTK is almost a strong enough argument on its own to move it to pivot-core.
>
> Maybe it should?
It has been moved to pivot-core and renamed BXMLSerializer for Pivot 2.0.
> One thing that's been bugging me as I work on my first Pivot project is the verbosity of specifying styles on elements. Why can't styles be specified as attributes on the element in their own right? Instead of
>
> <BoxPane styles="{ backgroundColor: 'red', horizontalAlignment: 'left' }"/>
>
> how about
>
> <BoxPane backgroundColor="red" horizontalAlignment="left"/>
That could be a bit confusing, since it looks like they are properties of the BoxPane. However, you can do this if you prefer:
<BoxPane>
<styles backgroundColor="red" horizontalAlignment="left"/>
</BoxPane>
Re: WTKXSerializer -> BeanSerializer
Posted by Michael Allman <ms...@allman.ms>.
On Mon, 19 Apr 2010, Greg Brown wrote:
> The fact that WTKXSerializer doesn't have any dependencies on WTK is
> almost a strong enough argument on its own to move it to pivot-core.
Maybe it should?
WTKX and WTKXSerializer are very elegant in their simplicity, but they
aren't as convenient as they could be for UI markup. And that's what WTKX
is for, right?
One thing that's been bugging me as I work on my first Pivot project is
the verbosity of specifying styles on elements. Why can't styles be
specified as attributes on the element in their own right? Instead of
<BoxPane styles="{ backgroundColor: 'red', horizontalAlignment: 'left' }"/>
how about
<BoxPane backgroundColor="red" horizontalAlignment="left"/>
?
The latter syntax is significantly more compact and IMHO much more
readable. Of course, there's no reason the current syntax for settings
styles couldn't be retained.
To handle this syntax, the parser could look for a skin property matching
an attribute name if the component itself has no such property.
Cheers,
Michael
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
> To me, have some code deprecated without having a new alternative
> gives mind stress :-) .
I agree. :-) The deprecated features in TextArea and TextInput kinda fall into that category, but I highly doubt that they will affect many users.
Re: WTKXSerializer -> BeanSerializer
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
> I'm not actually suggesting that @BXML is any clearer than @WTKX. I just think it is clearer than "resource", which, in my opinion, is too overloaded.
I agree with you.
> "Resource" refers to resource bundles, resource files, REST resources, etc. @BXML may not be 100% intuitive, but it is considerably less ambiguous than "resource", and it makes sense once you know what it is.
I agree also here, so my proposal for "PivotResource" but I'm lazy so
writing less is better also for me :-), and a name is only a name, the
important is that it will be clear what it means.
> This was sort of meant as a joke. I just meant that it is easier to speak. People complain about "WTKX". They want to know how they can shorten it - they don't want to have to say "W - T - K - X". "BXML" obviously has the same problem, but at least "bx" and "BeanSerializer" are easier to say. ;-)
I understand your point of view.
> As I was thinking about this, I kind of mentally settled on "bx" for the prefix, because it is short (less typing), and ".bxml" for the extension (since that is a natural translation of "bean XML"). It also parallels the Flex convention of "mx" and ".mxml".
I'd prefer something more "pivot-oriented" but to me also this sounds good.
I'm only trying to understand if having something at the start of the
name (here in the namespace, and also in the annotation) referring to
pivot is it would be a better default, like in an IDE in a project
containing many libraries "I'm searching the Pivot Annotation for
resources" or "what is the default namespace for pivot components" ...
so maybe typing P and seeing what the IDE suggest could be more simple
... but no more.
> It actually won't require much of a rewrite - it's pretty much a straight rename/move.
I wanted to get it in for 1.5, but unfortunately I think it will be
too disruptive. So it is probably best assigned to 2.0.
Ok, so you don't deprecate classes and method now ... probably is
better at the moment.
To me, have some code deprecated without having a new alternative
gives mind stress :-) .
Thanks,
Sandro
Re: WTKXSerializer -> BeanSerializer
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
> I'm not actually suggesting that @BXML is any clearer than @WTKX. I just think it is clearer than "resource", which, in my opinion, is too overloaded.
I agree with you.
> "Resource" refers to resource bundles, resource files, REST resources, etc. @BXML may not be 100% intuitive, but it is considerably less ambiguous than "resource", and it makes sense once you know what it is.
I agree also here, so my proposal for "PivotResource" but I'm lazy so
writing less is better also for me :-), and a name is only a name, the
important is that it will be clear what it means.
> This was sort of meant as a joke. I just meant that it is easier to speak. People complain about "WTKX". They want to know how they can shorten it - they don't want to have to say "W - T - K - X". "BXML" obviously has the same problem, but at least "bx" and "BeanSerializer" are easier to say. ;-)
I understand your point of view.
> As I was thinking about this, I kind of mentally settled on "bx" for the prefix, because it is short (less typing), and ".bxml" for the extension (since that is a natural translation of "bean XML"). It also parallels the Flex convention of "mx" and ".mxml".
I'd prefer something more "pivot-oriented" but to me also this sounds good.
I'm only trying to understand if having something at the start of the
name (here in the namespace, and also in the annotation) referring to
pivot is it would be a better default, like in an IDE in a project
containing many libraries "I'm searching the Pivot Annotation for
resources" or "what is the default namespace for pivot components" ...
so maybe typing P and seeing what the IDE suggest could be more simple
... but no more.
> It actually won't require much of a rewrite - it's pretty much a straight rename/move.
I wanted to get it in for 1.5, but unfortunately I think it will be
too disruptive. So it is probably best assigned to 2.0.
Ok, so you don't deprecate classes and method now ... probably is
better at the moment.
To me, have some code deprecated without having a new alternative
gives mind stress :-) .
Thanks,
Sandro
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
>> Rename @WTKX to @BXML
> For me is the same, but I don't think that BXML is more
> readable/simple to understand that WTKX, also when the default
> extension for related files in wtkx.
> Do you like "PivotResource" ?
I'm not actually suggesting that @BXML is any clearer than @WTKX. I just think it is clearer than "resource", which, in my opinion, is too overloaded. "Resource" refers to resource bundles, resource files, REST resources, etc. @BXML may not be 100% intuitive, but it is considerably less ambiguous than "resource", and it makes sense once you know what it is.
>> Of course, another thing to consider is that "BeanSerializer" and "bx" are a lot easier to say than "WTKXSerializer" and "wtkx".
> Are you sure ? To me sound similar, and "BeanSerializer" could be too
> much general (maybe confused with other libraries), but it's a
> question of taste.
This was sort of meant as a joke. I just meant that it is easier to speak. People complain about "WTKX". They want to know how they can shorten it - they don't want to have to say "W - T - K - X". "BXML" obviously has the same problem, but at least "bx" and "BeanSerializer" are easier to say. ;-)
>> There is a question of what prefix to use for the internal processing namespace (currently "wtkx"). Should this continue to be "wtkx" for WTKX files, or should it be something more generic ("bxml", "bx", "jbx", etc.)? This prefix could also be used as a generic file extension for bean markup files when a more appropriate extension is not available.
> So why not "pivot" (or a compressed form of it like "p" or "piv") ?
> General and directly related to Pivot, but in some cases maybe this
> could generate confusion like "a Pivot Application" or "a Pivot
> resource".
As I was thinking about this, I kind of mentally settled on "bx" for the prefix, because it is short (less typing), and ".bxml" for the extension (since that is a natural translation of "bean XML"). It also parallels the Flex convention of "mx" and ".mxml".
>> So I will move this ticket to 2.0.
> Probably is better, so we have more time to think/rewrite it better,
> without the need to keep backward compatibility.
> But do you think to start to put something in the 1.5.x release (new
> content, without changing the existing classes), and deprecate the old
It actually won't require much of a rewrite - it's pretty much a straight rename/move. I wanted to get it in for 1.5, but unfortunately I think it will be too disruptive. So it is probably best assigned to 2.0.
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
>> Rename @WTKX to @BXML
> For me is the same, but I don't think that BXML is more
> readable/simple to understand that WTKX, also when the default
> extension for related files in wtkx.
> Do you like "PivotResource" ?
I'm not actually suggesting that @BXML is any clearer than @WTKX. I just think it is clearer than "resource", which, in my opinion, is too overloaded. "Resource" refers to resource bundles, resource files, REST resources, etc. @BXML may not be 100% intuitive, but it is considerably less ambiguous than "resource", and it makes sense once you know what it is.
>> Of course, another thing to consider is that "BeanSerializer" and "bx" are a lot easier to say than "WTKXSerializer" and "wtkx".
> Are you sure ? To me sound similar, and "BeanSerializer" could be too
> much general (maybe confused with other libraries), but it's a
> question of taste.
This was sort of meant as a joke. I just meant that it is easier to speak. People complain about "WTKX". They want to know how they can shorten it - they don't want to have to say "W - T - K - X". "BXML" obviously has the same problem, but at least "bx" and "BeanSerializer" are easier to say. ;-)
>> There is a question of what prefix to use for the internal processing namespace (currently "wtkx"). Should this continue to be "wtkx" for WTKX files, or should it be something more generic ("bxml", "bx", "jbx", etc.)? This prefix could also be used as a generic file extension for bean markup files when a more appropriate extension is not available.
> So why not "pivot" (or a compressed form of it like "p" or "piv") ?
> General and directly related to Pivot, but in some cases maybe this
> could generate confusion like "a Pivot Application" or "a Pivot
> resource".
As I was thinking about this, I kind of mentally settled on "bx" for the prefix, because it is short (less typing), and ".bxml" for the extension (since that is a natural translation of "bean XML"). It also parallels the Flex convention of "mx" and ".mxml".
>> So I will move this ticket to 2.0.
> Probably is better, so we have more time to think/rewrite it better,
> without the need to keep backward compatibility.
> But do you think to start to put something in the 1.5.x release (new
> content, without changing the existing classes), and deprecate the old
It actually won't require much of a rewrite - it's pretty much a straight rename/move. I wanted to get it in for 1.5, but unfortunately I think it will be too disruptive. So it is probably best assigned to 2.0.
Re: WTKXSerializer -> BeanSerializer
Posted by Sandro Martini <sa...@gmail.com>.
Hi,
for me moving it into core is good.
But we could use this also in a server side application (and if Spring
or another JSR-250 compliant library is already used there) so
attention on the name we choose (to avoid confusion), but for me one
name is good as another.
> Rename @WTKX to @BXML
For me is the same, but I don't think that BXML is more
readable/simple to understand that WTKX, also when the default
extension for related files in wtkx.
Do you like "PivotResource" ?
> Of course, another thing to consider is that "BeanSerializer" and "bx" are a lot easier to say than "WTKXSerializer" and "wtkx".
Are you sure ? To me sound similar, and "BeanSerializer" could be too
much general (maybe confused with other libraries), but it's a
question of taste.
> There is a question of what prefix to use for the internal processing namespace (currently "wtkx"). Should this continue to be "wtkx" for WTKX files, or should it be something more generic ("bxml", "bx", "jbx", etc.)? This prefix could also be used as a generic file extension for bean markup files when a more appropriate extension is not available.
So why not "pivot" (or a compressed form of it like "p" or "piv") ?
General and directly related to Pivot, but in some cases maybe this
could generate confusion like "a Pivot Application" or "a Pivot
resource".
> it is also possible that simply using .xml as a standard file extension would be best, since that covers all cases and doesn't require developers to map XML syntax highlighter templates to a multitude of custom extensions.
yes, probably this is a good thing.
> So I will move this ticket to 2.0.
Probably is better, so we have more time to think/rewrite it better,
without the need to keep backward compatibility.
But do you think to start to put something in the 1.5.x release (new
content, without changing the existing classes), and deprecate the old
?
Bye,
Sandro
Re: WTKXSerializer -> BeanSerializer
Posted by Sandro Martini <sa...@gmail.com>.
Hi,
for me moving it into core is good.
But we could use this also in a server side application (and if Spring
or another JSR-250 compliant library is already used there) so
attention on the name we choose (to avoid confusion), but for me one
name is good as another.
> Rename @WTKX to @BXML
For me is the same, but I don't think that BXML is more
readable/simple to understand that WTKX, also when the default
extension for related files in wtkx.
Do you like "PivotResource" ?
> Of course, another thing to consider is that "BeanSerializer" and "bx" are a lot easier to say than "WTKXSerializer" and "wtkx".
Are you sure ? To me sound similar, and "BeanSerializer" could be too
much general (maybe confused with other libraries), but it's a
question of taste.
> There is a question of what prefix to use for the internal processing namespace (currently "wtkx"). Should this continue to be "wtkx" for WTKX files, or should it be something more generic ("bxml", "bx", "jbx", etc.)? This prefix could also be used as a generic file extension for bean markup files when a more appropriate extension is not available.
So why not "pivot" (or a compressed form of it like "p" or "piv") ?
General and directly related to Pivot, but in some cases maybe this
could generate confusion like "a Pivot Application" or "a Pivot
resource".
> it is also possible that simply using .xml as a standard file extension would be best, since that covers all cases and doesn't require developers to map XML syntax highlighter templates to a multitude of custom extensions.
yes, probably this is a good thing.
> So I will move this ticket to 2.0.
Probably is better, so we have more time to think/rewrite it better,
without the need to keep backward compatibility.
But do you think to start to put something in the 1.5.x release (new
content, without changing the existing classes), and deprecate the old
?
Bye,
Sandro
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
FYI, I just prototyped this. It wouldn't be terribly difficult to support backwards compatibility with WTKXSerializer for 1.x, but it will be a much more straightforward change for 2.0 if we don't need to do that. So I will move this ticket to 2.0.
On Apr 20, 2010, at 12:39 PM, Greg Brown wrote:
> I personally prefer the simpler "Resources" to "ResourceMap", so I don't think I would advocate renaming that class. I also don't think it is a huge priority for Pivot to support JSR-250 - to me, it doesn't seem like it would be a common use case.
>
> @BXML (like @WTKX) means that the member refers to an object declared in a BXML (or WTKX) file.
>
> I am currently thinking that this change could be made for Pivot 1.5, but in a backwards compatible way. Then, in Pivot 2.0, we'd drop the backwards compatibility.
>
> On Apr 20, 2010, at 12:30 PM, Dirk Möbius wrote:
>
>> Greg Brown <gk...@mac.com> wrote:
>>> However, I think the "Resources" name clash would cause confusion, so I think it would be preferable to stick with the existing terminology and not attempt to support JSR-250 (the end result is the same either way).
>>
>> The (now dead) Swing Application Framework (SAF) called it "ResourceMap" to avoid the confusion.
>>
>> This is for Pivot 2.0, isn't it? +1 for renaming Resources to ResourceMap and to support those parts of JSR-250. This makes it easier for newbies: if a new user sees the the @Resource annotation in Pivot code the first time, he knows immediately what this means. The @BXML annotation doesn't say anything.
>>
>> Dirk.
>>
>>
>>
>
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
FYI, I just prototyped this. It wouldn't be terribly difficult to support backwards compatibility with WTKXSerializer for 1.x, but it will be a much more straightforward change for 2.0 if we don't need to do that. So I will move this ticket to 2.0.
On Apr 20, 2010, at 12:39 PM, Greg Brown wrote:
> I personally prefer the simpler "Resources" to "ResourceMap", so I don't think I would advocate renaming that class. I also don't think it is a huge priority for Pivot to support JSR-250 - to me, it doesn't seem like it would be a common use case.
>
> @BXML (like @WTKX) means that the member refers to an object declared in a BXML (or WTKX) file.
>
> I am currently thinking that this change could be made for Pivot 1.5, but in a backwards compatible way. Then, in Pivot 2.0, we'd drop the backwards compatibility.
>
> On Apr 20, 2010, at 12:30 PM, Dirk Möbius wrote:
>
>> Greg Brown <gk...@mac.com> wrote:
>>> However, I think the "Resources" name clash would cause confusion, so I think it would be preferable to stick with the existing terminology and not attempt to support JSR-250 (the end result is the same either way).
>>
>> The (now dead) Swing Application Framework (SAF) called it "ResourceMap" to avoid the confusion.
>>
>> This is for Pivot 2.0, isn't it? +1 for renaming Resources to ResourceMap and to support those parts of JSR-250. This makes it easier for newbies: if a new user sees the the @Resource annotation in Pivot code the first time, he knows immediately what this means. The @BXML annotation doesn't say anything.
>>
>> Dirk.
>>
>>
>>
>
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
I personally prefer the simpler "Resources" to "ResourceMap", so I don't think I would advocate renaming that class. I also don't think it is a huge priority for Pivot to support JSR-250 - to me, it doesn't seem like it would be a common use case.
@BXML (like @WTKX) means that the member refers to an object declared in a BXML (or WTKX) file.
I am currently thinking that this change could be made for Pivot 1.5, but in a backwards compatible way. Then, in Pivot 2.0, we'd drop the backwards compatibility.
On Apr 20, 2010, at 12:30 PM, Dirk Möbius wrote:
> Greg Brown <gk...@mac.com> wrote:
>> However, I think the "Resources" name clash would cause confusion, so I think it would be preferable to stick with the existing terminology and not attempt to support JSR-250 (the end result is the same either way).
>
> The (now dead) Swing Application Framework (SAF) called it "ResourceMap" to avoid the confusion.
>
> This is for Pivot 2.0, isn't it? +1 for renaming Resources to ResourceMap and to support those parts of JSR-250. This makes it easier for newbies: if a new user sees the the @Resource annotation in Pivot code the first time, he knows immediately what this means. The @BXML annotation doesn't say anything.
>
> Dirk.
>
>
>
Re: WTKXSerializer -> BeanSerializer
Posted by Dirk Möbius <dm...@scoop-gmbh.de>.
Greg Brown <gk...@mac.com> wrote:
> However, I think the "Resources" name clash would cause confusion,
> so I think it would be preferable to stick with the existing
> terminology and not attempt to support JSR-250 (the end result is
> the same either way).
The (now dead) Swing Application Framework (SAF) called it
"ResourceMap" to avoid the confusion.
This is for Pivot 2.0, isn't it? +1 for renaming Resources to
ResourceMap and to support those parts of JSR-250. This makes it
easier for newbies: if a new user sees the the @Resource annotation in
Pivot code the first time, he knows immediately what this means. The
@BXML annotation doesn't say anything.
Dirk.
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
Of course, another thing to consider is that "BeanSerializer" and "bx" are a lot easier to say than "WTKXSerializer" and "wtkx". ;-)
On Apr 20, 2010, at 12:07 PM, Greg Brown wrote:
>>> - Move all classes in org.apache.pivot.wtkx to org.apache.pivot.beans
>>
>> Does this mean that it moves from pivot-wtk to pivot-core? Good.
>
> Yes.
>
>>> - Rename @WTKX to @BXML
>>
>> Why not use the standard @Resource annotation of JSR-250 (Common Annotations) which is specifically designed for dependency injection? Common Annotations are part of Java 6 SE. See http://en.wikipedia.org/wiki/JSR_250 . Also note that most DI tools such as Spring already support @Resource.
>>
>> Alas, the @Resources annotation of JSR-299 name-clashes with Pivot's Resources class, so that would need to be resolved...
>
> If I understand the intent correctly:
>
> @BXML ~= @Resource
> Bindable#initialize() ~= @PostConstruct
>
> However, I think the "Resources" name clash would cause confusion, so I think it would be preferable to stick with the existing terminology and not attempt to support JSR-250 (the end result is the same either way).
>
>> Other than that I don't care about the refactoring. I don't plan to use the Serializer for anything besides gui instantiation.
>
> OK, thanks.
>
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
Of course, another thing to consider is that "BeanSerializer" and "bx" are a lot easier to say than "WTKXSerializer" and "wtkx". ;-)
On Apr 20, 2010, at 12:07 PM, Greg Brown wrote:
>>> - Move all classes in org.apache.pivot.wtkx to org.apache.pivot.beans
>>
>> Does this mean that it moves from pivot-wtk to pivot-core? Good.
>
> Yes.
>
>>> - Rename @WTKX to @BXML
>>
>> Why not use the standard @Resource annotation of JSR-250 (Common Annotations) which is specifically designed for dependency injection? Common Annotations are part of Java 6 SE. See http://en.wikipedia.org/wiki/JSR_250 . Also note that most DI tools such as Spring already support @Resource.
>>
>> Alas, the @Resources annotation of JSR-299 name-clashes with Pivot's Resources class, so that would need to be resolved...
>
> If I understand the intent correctly:
>
> @BXML ~= @Resource
> Bindable#initialize() ~= @PostConstruct
>
> However, I think the "Resources" name clash would cause confusion, so I think it would be preferable to stick with the existing terminology and not attempt to support JSR-250 (the end result is the same either way).
>
>> Other than that I don't care about the refactoring. I don't plan to use the Serializer for anything besides gui instantiation.
>
> OK, thanks.
>
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
>> - Move all classes in org.apache.pivot.wtkx to org.apache.pivot.beans
>
> Does this mean that it moves from pivot-wtk to pivot-core? Good.
Yes.
>> - Rename @WTKX to @BXML
>
> Why not use the standard @Resource annotation of JSR-250 (Common Annotations) which is specifically designed for dependency injection? Common Annotations are part of Java 6 SE. See http://en.wikipedia.org/wiki/JSR_250 . Also note that most DI tools such as Spring already support @Resource.
>
> Alas, the @Resources annotation of JSR-299 name-clashes with Pivot's Resources class, so that would need to be resolved...
If I understand the intent correctly:
@BXML ~= @Resource
Bindable#initialize() ~= @PostConstruct
However, I think the "Resources" name clash would cause confusion, so I think it would be preferable to stick with the existing terminology and not attempt to support JSR-250 (the end result is the same either way).
> Other than that I don't care about the refactoring. I don't plan to use the Serializer for anything besides gui instantiation.
OK, thanks.
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
>> - Move all classes in org.apache.pivot.wtkx to org.apache.pivot.beans
>
> Does this mean that it moves from pivot-wtk to pivot-core? Good.
Yes.
>> - Rename @WTKX to @BXML
>
> Why not use the standard @Resource annotation of JSR-250 (Common Annotations) which is specifically designed for dependency injection? Common Annotations are part of Java 6 SE. See http://en.wikipedia.org/wiki/JSR_250 . Also note that most DI tools such as Spring already support @Resource.
>
> Alas, the @Resources annotation of JSR-299 name-clashes with Pivot's Resources class, so that would need to be resolved...
If I understand the intent correctly:
@BXML ~= @Resource
Bindable#initialize() ~= @PostConstruct
However, I think the "Resources" name clash would cause confusion, so I think it would be preferable to stick with the existing terminology and not attempt to support JSR-250 (the end result is the same either way).
> Other than that I don't care about the refactoring. I don't plan to use the Serializer for anything besides gui instantiation.
OK, thanks.
Re: WTKXSerializer -> BeanSerializer
Posted by Dirk Möbius <dm...@scoop-gmbh.de>.
my 2 cents:
> - Move all classes in org.apache.pivot.wtkx to org.apache.pivot.beans
Does this mean that it moves from pivot-wtk to pivot-core? Good.
> - Rename @WTKX to @BXML
Why not use the standard @Resource annotation of JSR-250 (Common
Annotations) which is specifically designed for dependency injection?
Common Annotations are part of Java 6 SE. See
http://en.wikipedia.org/wiki/JSR_250 . Also note that most DI tools
such as Spring already support @Resource.
Alas, the @Resources annotation of JSR-299 name-clashes with Pivot's
Resources class, so that would need to be resolved...
Other than that I don't care about the refactoring. I don't plan to
use the Serializer for anything besides gui instantiation.
Dirk.
Zitat von Greg Brown <gk...@mac.com>:
> Any comments on this? cc'ing the user list for additional feedback.
>
> On Apr 19, 2010, at 9:34 AM, Greg Brown wrote:
>
>> Hi all,
>>
>> I'd be very interested in any comments on this new ticket I entered
>> this morning:
>>
>> https://issues.apache.org/jira/browse/PIVOT-470
>>
>> The fact that WTKXSerializer doesn't have any dependencies on WTK
>> is almost a strong enough argument on its own to move it to
>> pivot-core. However, I think the concept of using it to support DI
>> and AOP is very interesting. I'd like to know what others think.
>>
>> G
>>
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
Any comments on this? cc'ing the user list for additional feedback.
On Apr 19, 2010, at 9:34 AM, Greg Brown wrote:
> Hi all,
>
> I'd be very interested in any comments on this new ticket I entered this morning:
>
> https://issues.apache.org/jira/browse/PIVOT-470
>
> The fact that WTKXSerializer doesn't have any dependencies on WTK is almost a strong enough argument on its own to move it to pivot-core. However, I think the concept of using it to support DI and AOP is very interesting. I'd like to know what others think.
>
> G
>
Re: WTKXSerializer -> BeanSerializer
Posted by Greg Brown <gk...@mac.com>.
Any comments on this? cc'ing the user list for additional feedback.
On Apr 19, 2010, at 9:34 AM, Greg Brown wrote:
> Hi all,
>
> I'd be very interested in any comments on this new ticket I entered this morning:
>
> https://issues.apache.org/jira/browse/PIVOT-470
>
> The fact that WTKXSerializer doesn't have any dependencies on WTK is almost a strong enough argument on its own to move it to pivot-core. However, I think the concept of using it to support DI and AOP is very interesting. I'd like to know what others think.
>
> G
>