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 <t....@curecomp.com> on 2012/07/05 14:32:39 UTC
AW: [DISCUSS] I18N MessageTemplate
Thomas Herzog <t....@curecomp.com> hat geschrieben:@All
Wouldn't it be fine to use convention over configuration within i18n module at property keys definition via @MessageTemplate?
I read the user doc and it did not mention it.
Also the oportunity to define a alternativ property file location would be fine, and to define the supported locales.
// As in cal10n, Different location for properties file.
@Base("META-INF/messages")
// As cal10n, supported locales, shall be evaluated, if files are present.
@Locales({@Locale("de_DE"), @Locale("en_US")})
class MessageHolder () {
// Would resolve to property key: MY_KEY
Strin getMyKey();
String myKey();
// Overwrites convention
@MessageTemplate("ERROR_USER_WRONG")
String getErrorForWrongUserDetected()
}
Would you aggree?
Is that already possible to define different location of the properties file and that method names get resolved to property keys without annotation?
One question more, is it possible to access the implementation of the message resource via EL within the view?
Re: [DISCUSS] I18N MessageTemplate
Posted by Mark Struberg <st...@yahoo.de>.
EL in config is not easy to understand and most times a real overkill.
Do you have a good use case where this could be needed?
LieGrue,
strub
----- Original Message -----
> From: Gerhard Petracek <ge...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Friday, July 6, 2012 9:52 PM
> Subject: Re: [DISCUSS] I18N MessageTemplate
>
> hi thomas,
>
> please have a look at the optional @MessageContextConfig annotation.
> after we have the basic parts, we could add e.g. the spi provided by
> myfaces codi to support el expressions in messages.
>
> regards,
> gerhard
>
>
>
> 2012/7/5 Thomas Herzog <t....@curecomp.com>
>
>> Thomas Herzog <t....@curecomp.com> hat geschrieben:@All
>> Wouldn't it be fine to use convention over configuration within i18n
>> module at property keys definition via @MessageTemplate?
>> I read the user doc and it did not mention it.
>> Also the oportunity to define a alternativ property file location would be
>> fine, and to define the supported locales.
>>
>> // As in cal10n, Different location for properties file.
>> @Base("META-INF/messages")
>> // As cal10n, supported locales, shall be evaluated, if files are present.
>> @Locales({@Locale("de_DE"), @Locale("en_US")})
>> class MessageHolder () {
>>
>> // Would resolve to property key: MY_KEY
>> Strin getMyKey();
>> String myKey();
>>
>> // Overwrites convention
>> @MessageTemplate("ERROR_USER_WRONG")
>> String getErrorForWrongUserDetected()
>> }
>>
>> Would you aggree?
>> Is that already possible to define different location of the properties
>> file and that method names get resolved to property keys without
> annotation?
>> One question more, is it possible to access the implementation of the
>> message resource via EL within the view?
>>
>>
>
Re: [DISCUSS] I18N MessageTemplate
Posted by Gerhard Petracek <ge...@gmail.com>.
hi thomas,
please have a look at the optional @MessageContextConfig annotation.
after we have the basic parts, we could add e.g. the spi provided by
myfaces codi to support el expressions in messages.
regards,
gerhard
2012/7/5 Thomas Herzog <t....@curecomp.com>
> Thomas Herzog <t....@curecomp.com> hat geschrieben:@All
> Wouldn't it be fine to use convention over configuration within i18n
> module at property keys definition via @MessageTemplate?
> I read the user doc and it did not mention it.
> Also the oportunity to define a alternativ property file location would be
> fine, and to define the supported locales.
>
> // As in cal10n, Different location for properties file.
> @Base("META-INF/messages")
> // As cal10n, supported locales, shall be evaluated, if files are present.
> @Locales({@Locale("de_DE"), @Locale("en_US")})
> class MessageHolder () {
>
> // Would resolve to property key: MY_KEY
> Strin getMyKey();
> String myKey();
>
> // Overwrites convention
> @MessageTemplate("ERROR_USER_WRONG")
> String getErrorForWrongUserDetected()
> }
>
> Would you aggree?
> Is that already possible to define different location of the properties
> file and that method names get resolved to property keys without annotation?
> One question more, is it possible to access the implementation of the
> message resource via EL within the view?
>
>