RE: Form#anyComponentError change in 1.4 breaks validation
Created JIRA issue w/quickstart (includes junit test): https://issues.apache.org/jira/browse/WICKET-2734 RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.com 304 West Route 38, Moorestown, NJ 08057 -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, February 08, 2010 10:00 PM To: users@wicket.apache.org Subject: Re: Form#anyComponentError change in 1.4 breaks validation yes, that would definately help, as well as a testcase. -igor On Mon, Feb 8, 2010 at 6:22 PM, Russell Morrisey russell.morri...@missionse.com wrote: Thanks Igor, It seems like maybe WICKET-2026 is also related: http://issues.apache.org/jira/browse/WICKET-2026 This changes how Form#anyFormComponentError handles border components, it looks like, but also switches us to a FormComponent visitor. Will it be helpful if I create a new JIRA issue? RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.com 304 West Route 38, Moorestown, NJ 08057 -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, February 08, 2010 1:20 PM To: users@wicket.apache.org Cc: Juergen Donnerstag Subject: Re: Form#anyComponentError change in 1.4 breaks validation Juergen, do you remember what the problem was taking out the instanceof checks for Form and FormComponent? i dont see why they were added or why removing them would cause problems... seems some changes are related to WICKET-2202 cheers -igor On Mon, Feb 8, 2010 at 9:14 AM, Russell Morrisey russell.morri...@missionse.com wrote: We are in the process of upgrading our application from wicket 1.3 to 1.4.5. There were a lot of minor changes due to the generics-related code changes, but for the most part the upgrade has been smooth. One big problem we've recently come across: Form#anyComponentError was changed in this version. This is a breaking change for our application, with no simple workaround provided. Please consider rolling it back to the previous behavior. In the previous version of wicket, all types of components in the Form's child hierarchy were checked for component.hasErrorMessage() during form validation; any error registered against a component would cause a validation failure. In the new version, only instances of Form or FormComponent are checked; errors registered against other components are ignored. Example use case: We have a customized inmethod DataGrid (excellent component!) which displays line items from a project estimate (ROM details). Each line item is identified by a number of reference fields, such as the Module which will be affected by the change, and the Paragraph of the spec which specifies the requirements for the change. The grid has a validation which ensures that a new line item isn't a duplicate (i.e., doesn't have the same Module/Paragraph/etc. combination). It seems to make the most sense to register the error against the DataGrid row, since the row represents the line item that is a duplicate; but the new Form validation logic ignores this change and saves the duplicate into the database. We want the row to detect when it has a validation error registered, and show a new CSS class (marking the row as invalid by making it orange) when we detect the duplicate; but it doesn't make sense to ascribe the validation error to a particular FormComponent on the row. I don't think the hierarchy of the datagrid permits us to make the row itself a Form without extensive changes. Please let me know what you guys think. I can resend this to the dev mailing list if it's more helpful, or put up a JIRA issue. RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.comhttp://www.missionse.com/ 304 West Route 38, Moorestown, NJ 08057 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose
Re: Form#anyComponentError change in 1.4 breaks validation
Juergen, do you remember what the problem was taking out the instanceof checks for Form and FormComponent? i dont see why they were added or why removing them would cause problems... seems some changes are related to WICKET-2202 cheers -igor On Mon, Feb 8, 2010 at 9:14 AM, Russell Morrisey russell.morri...@missionse.com wrote: We are in the process of upgrading our application from wicket 1.3 to 1.4.5. There were a lot of minor changes due to the generics-related code changes, but for the most part the upgrade has been smooth. One big problem we've recently come across: Form#anyComponentError was changed in this version. This is a breaking change for our application, with no simple workaround provided. Please consider rolling it back to the previous behavior. In the previous version of wicket, all types of components in the Form's child hierarchy were checked for component.hasErrorMessage() during form validation; any error registered against a component would cause a validation failure. In the new version, only instances of Form or FormComponent are checked; errors registered against other components are ignored. Example use case: We have a customized inmethod DataGrid (excellent component!) which displays line items from a project estimate (ROM details). Each line item is identified by a number of reference fields, such as the Module which will be affected by the change, and the Paragraph of the spec which specifies the requirements for the change. The grid has a validation which ensures that a new line item isn't a duplicate (i.e., doesn't have the same Module/Paragraph/etc. combination). It seems to make the most sense to register the error against the DataGrid row, since the row represents the line item that is a duplicate; but the new Form validation logic ignores this change and saves the duplicate into the database. We want the row to detect when it has a validation error registered, and show a new CSS class (marking the row as invalid by making it orange) when we detect the duplicate; but it doesn't make sense to ascribe the validation error to a particular FormComponent on the row. I don't think the hierarchy of the datagrid permits us to make the row itself a Form without extensive changes. Please let me know what you guys think. I can resend this to the dev mailing list if it's more helpful, or put up a JIRA issue. RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.comhttp://www.missionse.com/ 304 West Route 38, Moorestown, NJ 08057 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Form#anyComponentError change in 1.4 breaks validation
Thanks Igor, It seems like maybe WICKET-2026 is also related: http://issues.apache.org/jira/browse/WICKET-2026 This changes how Form#anyFormComponentError handles border components, it looks like, but also switches us to a FormComponent visitor. Will it be helpful if I create a new JIRA issue? RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.com 304 West Route 38, Moorestown, NJ 08057 -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, February 08, 2010 1:20 PM To: users@wicket.apache.org Cc: Juergen Donnerstag Subject: Re: Form#anyComponentError change in 1.4 breaks validation Juergen, do you remember what the problem was taking out the instanceof checks for Form and FormComponent? i dont see why they were added or why removing them would cause problems... seems some changes are related to WICKET-2202 cheers -igor On Mon, Feb 8, 2010 at 9:14 AM, Russell Morrisey russell.morri...@missionse.com wrote: We are in the process of upgrading our application from wicket 1.3 to 1.4.5. There were a lot of minor changes due to the generics-related code changes, but for the most part the upgrade has been smooth. One big problem we've recently come across: Form#anyComponentError was changed in this version. This is a breaking change for our application, with no simple workaround provided. Please consider rolling it back to the previous behavior. In the previous version of wicket, all types of components in the Form's child hierarchy were checked for component.hasErrorMessage() during form validation; any error registered against a component would cause a validation failure. In the new version, only instances of Form or FormComponent are checked; errors registered against other components are ignored. Example use case: We have a customized inmethod DataGrid (excellent component!) which displays line items from a project estimate (ROM details). Each line item is identified by a number of reference fields, such as the Module which will be affected by the change, and the Paragraph of the spec which specifies the requirements for the change. The grid has a validation which ensures that a new line item isn't a duplicate (i.e., doesn't have the same Module/Paragraph/etc. combination). It seems to make the most sense to register the error against the DataGrid row, since the row represents the line item that is a duplicate; but the new Form validation logic ignores this change and saves the duplicate into the database. We want the row to detect when it has a validation error registered, and show a new CSS class (marking the row as invalid by making it orange) when we detect the duplicate; but it doesn't make sense to ascribe the validation error to a particular FormComponent on the row. I don't think the hierarchy of the datagrid permits us to make the row itself a Form without extensive changes. Please let me know what you guys think. I can resend this to the dev mailing list if it's more helpful, or put up a JIRA issue. RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.comhttp://www.missionse.com/ 304 West Route 38, Moorestown, NJ 08057 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form#anyComponentError change in 1.4 breaks validation
yes, that would definately help, as well as a testcase. -igor On Mon, Feb 8, 2010 at 6:22 PM, Russell Morrisey russell.morri...@missionse.com wrote: Thanks Igor, It seems like maybe WICKET-2026 is also related: http://issues.apache.org/jira/browse/WICKET-2026 This changes how Form#anyFormComponentError handles border components, it looks like, but also switches us to a FormComponent visitor. Will it be helpful if I create a new JIRA issue? RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.com 304 West Route 38, Moorestown, NJ 08057 -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, February 08, 2010 1:20 PM To: users@wicket.apache.org Cc: Juergen Donnerstag Subject: Re: Form#anyComponentError change in 1.4 breaks validation Juergen, do you remember what the problem was taking out the instanceof checks for Form and FormComponent? i dont see why they were added or why removing them would cause problems... seems some changes are related to WICKET-2202 cheers -igor On Mon, Feb 8, 2010 at 9:14 AM, Russell Morrisey russell.morri...@missionse.com wrote: We are in the process of upgrading our application from wicket 1.3 to 1.4.5. There were a lot of minor changes due to the generics-related code changes, but for the most part the upgrade has been smooth. One big problem we've recently come across: Form#anyComponentError was changed in this version. This is a breaking change for our application, with no simple workaround provided. Please consider rolling it back to the previous behavior. In the previous version of wicket, all types of components in the Form's child hierarchy were checked for component.hasErrorMessage() during form validation; any error registered against a component would cause a validation failure. In the new version, only instances of Form or FormComponent are checked; errors registered against other components are ignored. Example use case: We have a customized inmethod DataGrid (excellent component!) which displays line items from a project estimate (ROM details). Each line item is identified by a number of reference fields, such as the Module which will be affected by the change, and the Paragraph of the spec which specifies the requirements for the change. The grid has a validation which ensures that a new line item isn't a duplicate (i.e., doesn't have the same Module/Paragraph/etc. combination). It seems to make the most sense to register the error against the DataGrid row, since the row represents the line item that is a duplicate; but the new Form validation logic ignores this change and saves the duplicate into the database. We want the row to detect when it has a validation error registered, and show a new CSS class (marking the row as invalid by making it orange) when we detect the duplicate; but it doesn't make sense to ascribe the validation error to a particular FormComponent on the row. I don't think the hierarchy of the datagrid permits us to make the row itself a Form without extensive changes. Please let me know what you guys think. I can resend this to the dev mailing list if it's more helpful, or put up a JIRA issue. RUSSELL E. MORRISEY Programmer Analyst Professional Mission Solutions Engineering, LLC | russell.morri...@missionse.com | www.missionse.comhttp://www.missionse.com/ 304 West Route 38, Moorestown, NJ 08057 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
