[
https://issues.apache.org/jira/browse/DELTASPIKE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408237#comment-13408237
]
Gerhard Petracek commented on DELTASPIKE-223:
---------------------------------------------
we could add an optional name-mapper to @MessageResource to map from the method
name to the message-key -> so it would be possible to customize the rules and
the default impl. don't have to care about topics like 'get'-prefix.
-> the default rule could be simpler - e.g.:
@MessageBundle
public interface SimpleMessage
{
String welcomeTo(String name);
}
->
welcomeTo=Welcome to %s
> Add convention for @MessageResource annotated types.
> ----------------------------------------------------
>
> Key: DELTASPIKE-223
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-223
> Project: DeltaSpike
> Issue Type: New Feature
> Components: I18n-Module
> Affects Versions: 0.2-incubating
> Reporter: Thomas Herzog
> Fix For: 0.3-incubating
>
>
> Add the possibility to use convention for @MessageResource annotated types.
> If there is no @MessageTemplate given for a defined method then the method
> itself shall provide the information for the property key.
> Example:
> @MessageResource
> class MyMessages() {
> String getErrorMessage();
> String getGetError();
> @MessageTemplate("MESSGAE_WARN")
> String getWarnMessage();
> }
> The convention would be:
> 1. If method name starts with 'get' remove it.
> 2. Split the method name at the upper case characters and seperate the parts
> with underscore.
> getErrorMessage() -> {Error, Message} -> ERROR_MESSAGE.
> getGetError() -> {Get, Error} -> GET_ERROR. (not pretty i know, just an
> example)
> getWarnMessage() is already defined
> Maybe the missing annotation could be added at the method of the type at
> deployment time.
> So there would be no need to provide property key name for every method,
> because if someone like me has a lot of messages and kept to the convention i
> described, it would be easier to switch to delta-spike i18n and also less
> work to do.
> So the existing implementation could be used as it is now. And during
> runtime, the interface would be as i18n needs it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
