The reason I want to avoid client tabs is speed. The form has several components that are slow to render (drop downs filled with REST service calls).
I ended up implementing this as follows: - An AjaxTabbedPanel with links that will submit the form currently shown (I look for the first child of class Form of the AjaxTabbedPanel but one could as well submit a form containing the AjaxTabbedPanel) - My own validation utility that validates objects using wicket's validation framework. This is more or less an object that allows the developer to attach validators to class properties. Then an object is validated by generating a Validatable object for each property and running the attached validators. Finally, errors are propagated to form components by matching the component id to the property name. - Validation runs on the entire object, not just one tab. So: - Every time the user tries to switch tabs, the form is submitted, and the entire object is validated. The errors relevant to the current tab are isolated and shown in a feedback panel inside the tab, and the tab-switching is cancelled. If there are no errors relevant to the current tab, the tab-switching goes ahead. - If the user clicks save, again the current form is submitted and the entire object is validated. If there are any errors, the user gets a popup message that indicates which tabs have errors. There are a few more details involved which I won't go into unless somebody wants to get the full story. Overall it's not a super clean solution, but it is not too bad either. Wicket again came through and made it possible to implement this scenario without much pain. And I'm quite happy with my "object validator". Because now I get a validator that can run both on a form (by validating it's model object) and on another channel of data entry (say a REST service) that reuses wicket's validators and error messages (so it's consistent with other forms that directly use wicket's validation). Marios On Wed, May 7, 2014 at 9:43 AM, Tom Götz <[email protected]> wrote: > The easiest solution I can think of. Why do you want to avoid that? > > Cheers, > -Tom > > On 06.05.2014, at 16:13, mscoon <[email protected]> wrote: > > > Is there a way to solve this? Client side tabs are a solution I guess but > > one I'd like to avoid if possible. > > > > >
