[ 
http://mifosforge.jira.com/browse/MIFOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel\#worklog-10150
 ]

jasmine sandhu logged work on MIFOS-4112:
-----------------------------------------

                  Author: jasmine sandhu
               Edited by: jasmine sandhu
              Created on: 13/Feb/11 8:56 PM
               Edited on: 13/Feb/11 9:00 PM
              Start Date: 13/Feb/11 8:26 PM 
      Worklog Time Spent: 5 hours 
        Work Description: Issue has been resolved. typeMismatch.* errors are 
not caught by the validator, they show up as a FieldError.  

A note on errors. There are two types reported in BindingResult object: 
(1) Binding errors - FieldErrors reported by spring encountered during binding 
like typeMismatch errors
(2) Validation errors - validation errors appended as ObjectError by 
LoanProductFormBeanValidator class

BindingResult object reports the errors as a list in 
${spring.status.errorMessages} where the order is to first report the binding 
errors (1) during the post, followed by the validation errors (2).

By default, spring passes the Field for which the error is reported to the 
DefaultMessageCodesResolver. So if the form backed object is a list as in the 
cases below, the second message code is typeMismatch.user.groups.name and the 
argument passed to it is loanAmountByLastLoanAmount[0].lower assuming that's 
the field that has the type mismatch error. 

Adding the following messages for these list objects now resolves these 
messages correctly. Since these additional messages are just numbers, it has no 
effect on the translations.

loanAmountByLastLoanAmount[0].lower=1
loanAmountByLastLoanAmount[1].lower=2
loanAmountByLastLoanAmount[2].lower=3
loanAmountByLastLoanAmount[3].lower=4
loanAmountByLastLoanAmount[4].lower=5
loanAmountByLastLoanAmount[5].lower=6

The corresponding messages for each of the fields have been added to 
messages.properties

The patch is made against hudsonBuild-hotWorkspace
    Work Description was: Issue has been resolved. typeMismatch.* errors are 
not caught by the validator, they show up as a FieldError.  

A note on errors. There are two types reported in BindingResult object: 
(1) Binding errors - FieldErrors reported by spring encountered during binding 
like typeMismatch errors
(2) Validation errors - validation errors appended as ObjectError by 
LoanProductFormBeanValidator class

BindingResult object reports the errors as a list in 
${spring.status.errorMessages} where the order is to first report the binding 
errors (1) during the post, followed by the validation errors (2).

By default, spring passes the Field for which the error is reported to the 
DefaultMessageCodesResolver. So if the form backed object is a list as in the 
cases below, the second message code is typeMismatch.user.groups.name and the 
argument passed to it is loanAmountByLastLoanAmount[0].lower assuming that's 
the field that has the type mismatch error. 

Adding the following messages for these list objects now resolves these 
messages correctly. Since these additional messages are just numbers, it has no 
effect on the translations.

loanAmountByLastLoanAmount[0].lower=1
loanAmountByLastLoanAmount[1].lower=2
loanAmountByLastLoanAmount[2].lower=3
loanAmountByLastLoanAmount[3].lower=4
loanAmountByLastLoanAmount[4].lower=5
loanAmountByLastLoanAmount[5].lower=6

The corresponding messages for each of the fields have been added to 
messages.properties

Issue Time Tracking
-------------------

    Worklog Id:     (was: 10150)
        
> Resolving MIFOS-3859 exposed a bug where typeMismatch.* error messages do not 
> display correctly
> -----------------------------------------------------------------------------------------------
>
>                 Key: MIFOS-4112
>                 URL: http://mifosforge.jira.com/browse/MIFOS-4112
>             Project: mifos
>          Issue Type: Bug
>          Components: Loan Account
>            Reporter: jasmine sandhu
>            Assignee: jasmine sandhu
>              Labels: volunteer
>             Fix For: Mifos Backlog
>
>         Attachments: 
> 0001-MIFOS-4112-fixed-the-display-of-the-error-messages-t.patch, 
> defineLoanProducts-test.html, typeMismatchError_after3859.png, 
> typeMismatchError_after3859.png, typeMismatchErrorOnCI_oldCode.png, 
> typeMismatchErrorOnCI_oldCode.png
>
>          Time Spent: 1 week, 3 days, 2 hours
>  Remaining Estimate: 0 minutes
>
> In fixing: http://mifosforge.jira.com/browse/MIFOS-3859
> the error messages displayed when the defineLoanProducts.flt form is 
> incorrectly filled are validated by LoanProductFormBeanValidator.java. This 
> class constructs the keys for the messages based on the constraint violation, 
> so if the field is null, it constructs a message as:
> NotNull.loanProduct.*
> This message is then read from messages.properties. The messages of the form: 
> typeMismatch.loanProduct.* are not being displayed correctly after this 
> parameterization. 
> As an example, if I enter a string for the first entry in the Last Loan 
> Amount table, it should trigger a typeMismatch error (see attached images).
> In the previous version, it appears the typeMismatch.* key was not being 
> read, but the error was nicer in that it displayed:
> Invalid data
> Now, with the update, the error reads the string from the key but does not 
> replace the parameter correctly. So it shows up as:
> Please Specify the valid Start Range Loan Amount for by last loan at row 
> loanAmountByLastLoanAmount[0].lower
> but it should show up as follows if the error occurred on row 1:
> Please Specify the valid Start Range Loan Amount for by last loan at row 1.
> The commit for Mifos-3859 is: 7d543c9621afadd7754e72b83401678b0bf410ca

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues

Reply via email to