[
https://issues.apache.org/jira/browse/TAP5-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dukaczewski updated TAP5-2439:
--------------------------------------
Description:
When customizing the label of an enum that is defined inside a class two
different key in the message catalog are needed.
Example, given the following class:
{code:title=Address.java}
public class Address {
public enum Honorific {MR, MRS, MISS, DR}
// [...]
}
{code}
Two entries per value in the message catalog are needed to get a consistent
output:
{code:title=app.properties}
Honorific.MR=Mr.
Address$Honorific.MR=Mr.
{code}
The problem is that there are two different methods in TapestryInternalUtils to
get a label for an enum:
{code:title=TapestryInternalUtils.java}
String getLabelForEnum(Messages messages, String prefix, Enum value)
String getLabelForEnum(Messages messages, Enum value)
{code}
The former is called by EnumSelectModel, where the latter is used by
PropertyDisplayBlocks.
Although the second method calls the first, but here the prefix is generated by
TapestryInternalUtils.lastTerm(). In the other callings of the first method
Class.toSimpleName() is used, which does not produce the same result.
I think the best solution would be to remove the method with 3 arguments
completely, because there is no meaningful use for it. All labels for an enum
should be generated consistent in the same way.
was:
When customizing the label of an enum that is defined inside a class two
different key in the message catalog are needed.
Example, given the following class:
public class Address {
public enum Honorific {MR, MRS, MISS, DR}
[...]
}
Two entries per value in the message catalog are needed to get a consistent
output:
Honorific.MR=Mr.
Address$Honorific.MR=Mr.
The problem is that there are two different methods in TapestryInternalUtils to
get a label for an enum:
TapestryInternalUtils.getLabelForEnum(Messages messages, String prefix, Enum
value)
TapestryInternalUtils.getLabelForEnum(Messages messages, Enum value)
The former is called by EnumSelectModel, where the latter is used by
PropertyDisplayBlocks.
Although the second method calls the first, but here the prefix is generated by
TapestryInternalUtils.lastTerm(). In the other callings of the first method,
Class.toSimpleName() is used, which does not produce the same result.
I think the best solution would be to remove the method with 3 arguments
completely, because there is no meaningful use for it. All labels for an enum
should be generated consistent in the same way.
> Inconsistent label keys in message catalog for enums
> ----------------------------------------------------
>
> Key: TAP5-2439
> URL: https://issues.apache.org/jira/browse/TAP5-2439
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.4
> Reporter: Michael Dukaczewski
> Priority: Minor
>
> When customizing the label of an enum that is defined inside a class two
> different key in the message catalog are needed.
> Example, given the following class:
> {code:title=Address.java}
> public class Address {
> public enum Honorific {MR, MRS, MISS, DR}
> // [...]
> }
> {code}
> Two entries per value in the message catalog are needed to get a consistent
> output:
> {code:title=app.properties}
> Honorific.MR=Mr.
> Address$Honorific.MR=Mr.
> {code}
> The problem is that there are two different methods in TapestryInternalUtils
> to get a label for an enum:
> {code:title=TapestryInternalUtils.java}
> String getLabelForEnum(Messages messages, String prefix, Enum value)
> String getLabelForEnum(Messages messages, Enum value)
> {code}
> The former is called by EnumSelectModel, where the latter is used by
> PropertyDisplayBlocks.
> Although the second method calls the first, but here the prefix is generated
> by TapestryInternalUtils.lastTerm(). In the other callings of the first
> method Class.toSimpleName() is used, which does not produce the same result.
> I think the best solution would be to remove the method with 3 arguments
> completely, because there is no meaningful use for it. All labels for an enum
> should be generated consistent in the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
