hi thomas, @ 'abstract class for easier handling of custom property files' vs. @Base vs. ... imo it's easier to discuss it based on an almost final basic api.
@ conventions: see my comment [1] - that would be way easier but still flexible imo @ access to the impl: it's a jdk proxy without delegation to an impl. class (see MessageBundleInvocationHandler) regards, gerhard [1] http://s.apache.org/y98 2012/7/6 Mark Struberg <[email protected]> > 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? > >> > >> > > > > > > >
