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.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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
