1.) The EL support for making it usable directly inside JSF pages sounds really reasonable! As we already create a dynamic bean, we can for sure also return a Bean#getName().
Can you please create an own Jira for it? I think this is more a 0.4 feature, as this is more of a frontend use case. 2.) I need to think about regarding the getXxx stuff. 3.) I don't like the base path, but a general property file name inside the @MessageBundle would be a big benefit I think. -> 0.4 LieGrue, strub PS: and welcome to deltaspike ;) >________________________________ > From: Thomas Herzog <[email protected]> >To: [email protected] >Sent: Friday, July 6, 2012 10:13 PM >Subject: WG: Re: [DISCUSS] I18N MessageTemplate > > > > >Hi gerhard > > >I will take look at this next week. >I am aware that there are the possibility to define an own messageresolver but >an custom one would do the same the only difference would be where to get >resources. If i were able to define the base path via annotation i would not >have the work to do that by myself. > > >The thing with the convention would be fine if it would be possible to define >the behavior at interpreting the method name as property key. We do have a >lots of message with the syntax MY_KEY. But the method name should be >getMyKey(); > > >This leads me to another question is it possible to acess the implementation >of the interface via EL in the view? >We do have an message bean which provides the messages. It is application >scoped cdi bean. >We thougt we could extract an interface an use the created implementation in >the view. I must admit i do not know how the implementation of the interface >gets created within the i18N module. >Is this possible? Or do we have to wrap it with injecting in an message bean? > > > > >Send via Samsung Galaxy S2 > > >-------- Ursprüngliche Nachricht -------- >Betreff: Re: [DISCUSS] I18N MessageTemplate >Von: Gerhard Petracek <[email protected]> >An: [email protected] >CC: > > >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 <[email protected]> > >> Thomas Herzog <[email protected]> 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? >> >> > > >
