|

»

»

[jira] Created: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change.

View: New views

9 Messages — Rating Filter: Alert me

	[jira] Created: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message get a valueChangeEvent for bigDecimal even though user didn't make a change. ---------------------------------------------------------------------------- Key: TRINIDAD-1489 URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. There are 2 workarounds for now. 1] apply the pattern to the bigdecimal in the getter, so in the salary example code above return newSal instead of sal. 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712307#action_12712307 ] Gabrielle Crawford commented on TRINIDAD-1489: ---------------------------------------------- added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 777741 > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Issue Comment Edited: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712307#action_12712307 ] Gabrielle Crawford edited comment on TRINIDAD-1489 at 5/22/09 4:33 PM: ----------------------------------------------------------------------- added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 777741 http://svn.apache.org/viewvc?view=rev&revision=777741 was (Author: gabrielle): added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 777741 > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712312#action_12712312 ] Gabrielle Crawford commented on TRINIDAD-1489: ---------------------------------------------- Currently there's this code in UIXEditableValue protected boolean compareValues(Object previous, Object value) { if (isEmpty(previous)) return !isEmpty(value); return !previous.equals(value); } The fix being proposed is that if the .equals fails we'll check if the two values are 1. the same type 2. implement comparable and if 1 and 2 are true we'll use compareTo > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Issue Comment Edited: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712307#action_12712307 ] Gabrielle Crawford edited comment on TRINIDAD-1489 at 5/22/09 4:44 PM: ----------------------------------------------------------------------- added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 777741 http://svn.apache.org/viewvc?view=rev&revision=777741 If you run the demo page, and don't change anything, but just hit the submit button on the test page you get a valueChangeEvent fired for the inputText with bigdecimal, even though you didn't change anything. was (Author: gabrielle): added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 777741 http://svn.apache.org/viewvc?view=rev&revision=777741 > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712408#action_12712408 ] Matthias Weßendorf commented on TRINIDAD-1489: ---------------------------------------------- yeah, this comes with JSF 2.x (I think 2.1) as well: http://wiki.java.net/bin/view/Projects/Jsf2MR1ChangeLog (see C007) > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Resolved: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabrielle Crawford resolved TRINIDAD-1489. ------------------------------------------ Resolution: Fixed Fix Version/s: 1.2.12-core > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > Fix For: 1.2.12-core > > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738863#action_12738863 ] Bastian Krol commented on TRINIDAD-1489: ---------------------------------------- In combination with a tr:selectOneChoice or similar controls this issue can even result in corrupt data as described here: http://www.nabble.com/f%3AconvertNumber-triggers-call-to-set-method-on-tr%3AinputText%2C-effectively-overwriting-the-property-in-the-wrong-object-td24741551.html#a24802996 > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > Fix For: 1.2.12-core > > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Issue Comment Edited: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change. by My Faces - Dev mailing list :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738863#action_12738863 ] Bastian Krol edited comment on TRINIDAD-1489 at 8/3/09 11:44 PM: ----------------------------------------------------------------- In combination with a tr:selectOneChoice or similar controls this issue can even result in corrupt data as described here: http://www.nabble.com/f%3AconvertNumber-triggers-call-to-set-method-on-tr%3AinputText%2C-effectively-overwriting-the-property-in-the-wrong-object-td24741551.html was (Author: basti1302): In combination with a tr:selectOneChoice or similar controls this issue can even result in corrupt data as described here: http://www.nabble.com/f%3AconvertNumber-triggers-call-to-set-method-on-tr%3AinputText%2C-effectively-overwriting-the-property-in-the-wrong-object-td24741551.html#a24802996 > get a valueChangeEvent for bigDecimal even though user didn't make a change. > ---------------------------------------------------------------------------- > > Key: TRINIDAD-1489 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 > Project: MyFaces Trinidad > Issue Type: Bug > Reporter: Gabrielle Crawford > Fix For: 1.2.12-core > > > When attribute data type is BigDecimal and <af:convertNumber> is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. > Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. > We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. > There are 2 workarounds for now. > 1] apply the pattern to the bigdecimal in the getter, so in the salary > example code above return newSal instead of sal. > 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.