I just want to get a couple things straight:
1. Your state names are in localised properties files
2. The properties files are available to struts2 either via
struts.custom.i18n.resources or convention (read don’t ask)
If you app satisfies these two points then the method I mentioned will work
fine. If it doesn’t, it’s not that much work to satisfy them.
Where specifically are you seeing a problem?
Z.
>
>
> This won't work for me because the list is not maintained in Action, rather
> in a properties file - since it's a set of constants (ex : list of US
> states)
>
>
>
> Sparecreative wrote:
>> >
>> > You don¹t have to have a DB back end.
>> >
>> > Here¹s a couple of examples from our system:
>> >
>> > <s:radio list="responses" listKey="responseKey"
>> > listValue="%{getText(responseValue)}" name="name"
>> > label="%{getText(responseLabel)}" />
>> >
>> > <s:select headerKey="" headerValue="%{getText('select')}" list="responses"
>> > listKey="responseKey" listValue="%{getText(responseValue)}" name="name"
>> > label="%{getText(responseLabel)}" />
>> >
>> > It¹s pretty self explanatory, but the getText function is called on your
>> > action. Obviously this is predicated on your actions either extending
>> > ActionSupport or implementing a getText method to retrieve localised
>> > values.
>> >
>> > Z.
>>> >>
>>> >>
>>> >> Yeah, i dont want to change to DB backed bundles. My question is if the
>>> >> s:select tag can take a list from a resourcebundle directly and use it .
>>> >> If
>>> >> so, how should the list be specified ?
>>> >>
>>> >> On Sat, Sep 5, 2009 at 3:59 AM, Tommy Pham <tommy...@yahoo.com> wrote:
>>> >>
>>>>> >>> > ----- Original Message ----
>>>>>>> >>>> > > From: j alex <strutstwou...@gmail.com>
>>>>>>> >>>> > > To: Struts Users Mailing List <user@struts.apache.org>
>>>>>>> >>>> > > Sent: Friday, September 4, 2009 12:48:43 PM
>>>>>>> >>>> > > Subject: [S2] i18n for lists/maps
>>>>>>> >>>> > >
>>>>>>> >>>> > > Hi,
>>>>>>> >>>> > >
>>>>>>> >>>> > > Normally, we use the resource bundles to store Strings like
field
>>>>> >>>> labels,
>>>>>>> >>>> > > error messages etc. But how about things like dropdown display
>>>>> >>>> values ?
>> > .
>>>>> >>> > I
>>>>>>> >>>> > > need to i18n-ize an app that has a lot of such dropdowns and
the
>>>>> >>>> lists
>>>>> >>> > are
>>>>>>> >>>> > > currently referenced like
>>>>>>> >>>> > > list="#application.dropdownmap['loanType']"/> where dropdownmap
is
>>>>> >>>> loaded
>>>>>>> >>>> > > into ServletContext from a properties file . that has
>>>>>>> definitions
>>>>> >>>> like :
>>>>>>> >>>> > > loanType=1~Home Loan|2~Car Loan|3~Refi etc. Here, the 1,2,3
remains
>>>>> >>> > constant
>>>>>>> >>>> > > but the display value will vary by locale.
>>>>>>> >>>> > >
>>>>>>> >>>> > > It'll be really neat if it's possible to maintain this list in
a
>>>>> >>>> typical
>>>>>>> >>>> > > resource bundle file like ApplicationResources_and be able to
use
>>>>>>> >>>> > > it from s:select tags without having to do any manual parsing.
Any
>>>>> >>>> inputs
>>>>>>> >>>> > > will be really helpful.
>>>>>>> >>>> > >
>>>>>>> >>>> > > Thanks!
>>>>> >>> >
>>>>> >>> > Hi Alex,
>>>>> >>> >
>>>>> >>> > I don't mean to advice you on adding more complexity to your project
>>>> >>> but
>>>>> >>> > Mike Baranski and I were discussing about using/getting the
>>>> >>> ResourceBundle
>>>>> >>> > from DB backend instead. He had one working:
>>>>> >>> >
>>>>> >>> > "Here you go, this is what I did. I don't know if it's the "best"
>>>> >>> way, but
>>>>> >>> > it works:
>>>>> >>> >
>>>>> >>> > http://mikeski.net/site/node/37
>>>>> >>> >
>>>>> >>> > Mike."
>>>>> >>> >
>>>>> >>> > I had planned on using DB backend instead solely so that anyone with
>>>> >>> the
>>>>> >>> > proper privileges via the web UI can add/change the texts. You only
>>>> >>> need
>>>> >>> to
>>>>> >>> > provide the proper db structure and key for the texts. If you do
>>>> >>> implement
>>>>> >>> > DB backend, IMHO, I think it will give you more flexibility for the
>>>> >>> future
>>>>> >>> > and less of the menial work ;), especially when they (your boss
>>>>> and/or
>>>>> >>> > client(s)) decide to use additional language.
>>>>> >>> >
>>>>> >>> > Regards,
>>>>> >>> > Tommy
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >
>>>>> ---------------------------------------------------------------------
>>>>> >>> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>>>>> >>> > For additional commands, e-mail: user-h...@struts.apache.org
>>>>> >>> >
>>>>> >>> >
>> >
>> >
>> >
