You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Thomas Herzog (JIRA)" <ji...@apache.org> on 2012/07/05 21:37:33 UTC
[jira] [Created] (DELTASPIKE-223) Add convention for
@MessageResource annotated types.
Thomas Herzog created DELTASPIKE-223:
----------------------------------------
Summary: 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
[jira] [Commented] (DELTASPIKE-223) Add convention for
@MessageResource annotated types.
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408908#comment-13408908 ]
Mark Struberg commented on DELTASPIKE-223:
------------------------------------------
no name mapper or any other over-engineered handling please. We are fine with just picking up the method name as resource key. Too much flexibility makes tooling impossible and will also confuse users. We now have a clear 1:1 rule which is flexible enough. A user can still use it's own @MessageTemplate!
> 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
> Assignee: Gerhard Petracek
> 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
[jira] [Resolved] (DELTASPIKE-223) Add convention for
@MessageResource annotated types.
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Struberg resolved DELTASPIKE-223.
--------------------------------------
Resolution: Fixed
> 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
> Assignee: Gerhard Petracek
> 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
[jira] [Comment Edited] (DELTASPIKE-223) Add convention for
@MessageResource annotated types.
Posted by "Gerhard Petracek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408237#comment-13408237 ]
Gerhard Petracek edited comment on DELTASPIKE-223 at 7/6/12 11:24 PM:
----------------------------------------------------------------------
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
(in case of the 'get'-prefix we could provide a fallback to support it as well)
was (Author: gpetracek):
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
> Assignee: Gerhard Petracek
> 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
[jira] [Assigned] (DELTASPIKE-223) Add convention for
@MessageResource annotated types.
Posted by "Gerhard Petracek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gerhard Petracek reassigned DELTASPIKE-223:
-------------------------------------------
Assignee: Gerhard Petracek
> 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
> Assignee: Gerhard Petracek
> 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
[jira] [Commented] (DELTASPIKE-223) Add convention for
@MessageResource annotated types.
Posted by "Gerhard Petracek (JIRA)" <ji...@apache.org>.
[ 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