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