On 12/16/06, JS Portal support team <[EMAIL PROTECTED]> wrote:
>But I would love to check in translated versions if I could find
>some volunteers to do the translations!
I can do this for Dutch and the other languages I will have done by
translators when I need them. But still I would like to know if there is
an EL way to perform something like:
<h:outputFormat escape="false" value="#{labels['err.requiredField']}">
<f:param value="#{labels['labels.user.email']}" />
</h:outputFormat>
for an attribute value?
I did some digging into the docs, and yes this kind of thing should be
possible. I'm presuming that above this component, you declared the
resource bundle to use:
<f:loadBundle name="labels" bundleName="..."/>
Now, the outputFormat component can look up a message string that might read
in English something like:
{0} is a required field
and the embedded <f:param> tags are used to define the replacement values.
I haven't actually confirmed that MyFaces does this correctly, but the
"Render Kit Documentation" included with the JSF RI, which is considered
required behavior for the renderers, says this should all work.
..But the developers there have been receptive to such changes.
I do need this feature and either will build it myself outside
Shale/commons, but would love to contribute to the project and work with
someone to implement. Who do I talk to though?
Thank you and looking forward to making this work.
The best way to propose new stuff (or provide things like the translated
resource bundles), is a combination of:
* Discuss the proposed changes on the Shale Developer list
(<http://shale.apache.org/mail-lists.html> for subscription info)
* Post an RFE or bug issue in our tracking system[1], and then
add your new files as attachments. If you propose changing
existing files, then adding the output of "svn diff" will allow the
Shale developers to both review the changes, and automatically
apply them if they're accepted.
Craig
[1] https://issues.apache.org/struts/browse/SHALE
Joost
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Tuesday, December 12, 2006 6:56 PM
To: [email protected]
Subject: Re: <s:commonsValidator> question
On 12/11/06, JS Portal support team <[EMAIL PROTECTED]> wrote:
>
> >If you do not specify messages for these keys in your own application
> >resource bundle, validator will fall back to its own default message
> >strings ... so you don't have to override these unless the defaults do
> not
> >help you.
>
> Does shale also internationalize these messages then? Also in Hebrew and
> Korean or any other script for that matter?
At the moment, Shale only includes the English and German translation of
the
messages. But I would love to check in translated versions if I could
find
some volunteers to do the translations! It's a matter of providing an
appropriate messages_XXX.properties file containing translations of the
English version, which can be found at [1]. The same applies to any other
message resource bundles found in the source base as well.
The best way to provide the translations would be to create an RFE issue
in
our tracking system[1], and add the appropriate properties files as an
enhancement. Like all resource bundles, don't forget to run native2ascii
if
the translations include on-USASCII7 characters.
>That is what would happen if the form is actually submitted, but the
client
> >side checks are designed to prevent the form submit from happening if
> there
> >are any errors detected there -- so things never get far enough along
for
> >the server side checks to kick in (unless you've disabled client side
> >Javascript).
>
> Why I asked is because I want to use the client check to prevent
> unneeded return trips to the server. I just don't like the looks of the
> alert. I was hoping shale also made a little client script available
> which populates the h:message with the appropriate error message.
That would be a great enhancement to the current functionality, but it's
not
there at present. It's also going to take a bit of refactoring in the
client side JavaScript code of Commons Validator, which currently mixes
the
logic (is the field valid) and presentation (do the popup) a little too
closely to be able to pull this off. But the developers there have been
receptive to such changes.
Thank you for your help,=
Craig
[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/resources/org/apache/shale/validator/messages.properties?revision=467172&view=markup
]2] https://issues.apache.org/struts/browse/SHALE
JS Portal - Support
> Dasstraat 21
> 2623CB Delft
> the Netherlands
> E: [EMAIL PROTECTED]
> W: www.jsportal.com
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
> McClanahan
> Sent: Tuesday, December 12, 2006 12:36 PM
> To: [email protected]
> Subject: Re: <s:commonsValidator> question
>
> On 12/11/06, JS Portal support team <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I have two questions concerning <s:commonsValidator> tag
> >
> > 1. Is there a way to set the message attribute of the
s:commonsValidator
> > with the value resulting from?:
> >
> > <h:outputFormat escape="false" value="#{labels['err.requiredField']}">
> > <f:param value="#{labels['labels.user.email']}" />
> > </h:outputFormat>
> >
> > This way I don't have to add a long list of err.required.email,
> > err.required.name etc. to my i18n properties files. Just a compilation
> > of my err.requiredField ({0} required) combined with the field name
will
> > be enough.
>
>
> If you do not specify messages for these keys in your own application
> resource bundle, validator will fall back to its own default message
> strings ... so you don't have to override these unless the defaults do
> not
> help you.
>
> 2. Is there a way to have the client check also print the error message
> > to the <h:message for="myField"/> in stead of having the JavaScript
> > alert pop up?
>
>
> That is what would happen if the form is actually submitted, but the
> client
> side checks are designed to prevent the form submit from happening if
> there
> are any errors detected there -- so things never get far enough along
for
> the server side checks to kick in (unless you've disabled client side
> Javascript).
>
> Thank you and have a great day,
> > Joost Schouten
> > Director
>
>
> Craig
>
>
> JS Portal
> > Dasstraat 21
> > 2623CB Delft
> > the Netherlands
> > P: +31 6 160 160 14
> > E: [EMAIL PROTECTED]
> > W: www.jsportal.com
> >
> >
>
>
