yes, that would definately help, as well as a testcase. -igor
On Mon, Feb 8, 2010 at 6:22 PM, Russell Morrisey <[email protected]> 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 > > | [email protected] | www.missionse.com > 304 West Route 38, Moorestown, NJ 08057 > > -----Original Message----- > From: Igor Vaynberg [mailto:[email protected]] > Sent: Monday, February 08, 2010 1:20 PM > To: [email protected] > 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 > <[email protected]> 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 >> >> | [email protected] | >> www.missionse.com<http://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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
