shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joost Schouten (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-372) messages_nl.properties
Date Thu, 28 Dec 2006 09:35:58 GMT
    [ http://issues.apache.org/struts/browse/SHALE-372?page=comments#action_39192 ] 
            
Joost Schouten commented on SHALE-372:
--------------------------------------

I currently solved my number chacking problem as follows:

<h:inputText id="myInteger" value="#{contact.myInteger}">
	<s:commonsValidator type="float" message="{0} should be a number" arg="#{labels['labels.user.myInteger']}"
server="true" client="true"/> 
        <!-- would like to use a double, but that fails. posted a message on the shale
user mailinglist-->
	<s:commonsValidator type="integer" arg="#{labels['labels.user.myInteger']}" server="true"
client="true"/>
</h:inputText>
<h:message for="myInteger" styleClass="error"/>

This results in a message telling my users to use a number, if they entered text or a wrong
format. Once that is correct, and it is a float in stead of an integer, they'll get told to
us an integer in stead.

Obviously I would propose to add a numbet validator type to the s:commonsValidator and a numberValidator
to the commons package. Do more people support this? If so I can build the validators and
submit them.

> messages_nl.properties
> ----------------------
>
>                 Key: SHALE-372
>                 URL: http://issues.apache.org/struts/browse/SHALE-372
>             Project: Shale
>          Issue Type: Improvement
>            Reporter: Joost Schouten
>             Fix For: 1.0.4-SNAPSHOT
>
>         Attachments: messages_nl.properties
>
>
> Hi,
> Here is the nl translation for the /shale/framework/trunk/shale-validator/src/main/resources/org/apache/shale/validator/messages.properties
> I'm not quite sure if the " should be escaped or not. Also, there is no propper translation
for float, integer etc. So I refered to them in their english name. However, I think it would
make sence to add some sort of pre-validator checking if the the parameter is a number or
not. If not, return a message like "{0} is not a number". This message is understood by the
endusers better than should be a float, integer etc. Once the validator detected a number
of the wrong kind display the error message indicating it is not the right type of number.
> I hope this all makes sence, and please correct me if I made a mistake in how I am contributing.
> Regards,
> Joost
> --------------------------------------------
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements.  See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to you under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License.  You may obtain a copy of the License at
> #
> #     http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> errors.required={0} is vereist. 
> errors.minlength={0} mag niet minder dan {1} karakter(s) hebben.
> errors.maxlength={0} mag niet meer dan {1} karakter(s) hebben.
> errors.invalid={0} is ongeldig.
> errors.byte={0} moet een "byte" zijn.
> errors.short={0} moet een "short" zijn. 
> errors.integer={0} moet een "integer" zijn.
> errors.long={0} moet een "long" zijn.
> errors.float={0} moet een "float" zijn.
> errors.double={0} moet een "double" zijn.
> errors.date={0} is geen datum.
> errors.range={0} valt buiten het bereik van {1} tot en met {2}.
> errors.creditcard={0} is een onjuist creditcardnummer.
> errors.email={0} is een onjuist e-mailadres.
> errors.url={0} is een onjuist url-adres.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message