You only need to implement one translator (which, if input is invalid can act
like a validator).
The translator will have 2 properties, yesString + noString
you'll define it in you .page like this:
<bean name="ynTranslator"
class="another.cool.Translator">
<set name="yesString" value="message:yesChar" />
<set name="noString" value="message:noChar" />
</bean>
and use it like this:
<binding name="translator" value="bean:ynTranslator" />
For each language you want to support, you just supply the localized
versions of yesChar and noChar in the appropriate .properties file.
>From Andreas Bulling <[EMAIL PROTECTED]>:
> | I'm sorry. My bad. I guess I didn't read your post too carefully.
>
> No problem ;)
>
> | AFAIK translator by design runs first so that your validator can check
> | on the intended value.
>
> Well, in this case in my opinion this is bad design, isn't it?
> For example if I just want two different characters to be
> accepted by the validator (say y/n) and want to save their translated
> values (say 1/0) in the database afterwards wouldn't it be more
> intuitive to first check if the characters are valid and
> translate _afterwards_?
>
> At the moment, first I have to write a translator which translates
> them to boolean values and a validator which accepts (or rejects)
> them afterwards: That means _in the translator_ I have to make
> a hardcoded check for y and n (in this case) to be able to
> translate them to correct boolean values. But
> 1) then the validator isn't useful anymore because the "logic"
> is in the translator class
> 2) I have to do this for every language I want to support. Bad. :(
>
> Sincerly,
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
