Comments on: Building a ListEditor form component

By: sam

sam — Thu, 24 Sep 2009 06:18:27 +0000

I’m getting this error:

java.lang.UnsupportedOperationException: Model class x.x.x.listeditor.ListEditorItem$ListItemModel does not support setObject(Object)
at org.apache.wicket.model.AbstractReadOnlyModel.setObject(AbstractReadOnlyModel.java:55)
at org.apache.wicket.Component.setDefaultModelObject(Component.java:3052)
at org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1168)

By: ivaynberg

ivaynberg — Thu, 30 Jul 2009 16:59:51 +0000

@John: Remember, the whole point of the ListEditor was that submit is atomic. The problem, I would guess, is that you use a regular TabbedPanel which uses a regular anchor link to switch tabs. That means the form is not submitted.

There are two ways to solve it:

a) Override tabbedpanel’s newLink() factory and return a SubmitLink instead – this will submit the form between tab switches.

b) Use a javascript tab panel instead so that everything is still kept on the same page.

By: John

John — Sat, 25 Jul 2009 15:48:35 +0000

Also, now when I switch tabs any updates get lost unless I have submitted the whole form. This is not very intuitive for the user as the tabs really just split up a very very long form which has many parts that are optional.

By: John

John — Fri, 24 Jul 2009 15:39:03 +0000

I had this working fine when everything was on a single page. I also used the above example to make it work with lists of strings.

Then I separated different parts of the form into panels on tabs. Now that it is in a panel the add button does not update its model so always adds an empty string.

I don’t see why it should behave differently. Any ideas?

The hierachy was..
form->listeditor stuff

The hierarchy is now..
form->tabbedpanel->panel->listeditor stuff

Maybe there is another problem with forms separated into panels but wizards do this fine..

Help!

By: ivaynberg

ivaynberg — Fri, 10 Jul 2009 04:14:20 +0000

@garz: Because we want all changes to the list to be comitted atomically when the form is submitted we make a copy of the actual list backing the model.

If we did not do this then operations such as move up and move down, for example, would immediately affect the model object before the form was submitted.

By: garz

garz — Thu, 09 Jul 2009 15:43:37 +0000

hi ivaynberg,

at first i want to thank you for this article. i have the book “wicket in action” and there it isnt explained the same way as it is here and i have the feeling, this solution is nicer than the one in the book. thank you very much!

i have one question. in the ListEditor-class in the method onBeforeRender() you set the items-attribute like this:
items = new ArrayList(getModelObject());
why not doing it like this:
items = getModelObject();
why do you create a new ArrayList-object? is it because the constructor supports the more general interface Collection? if so, why not using Collection as the type for the items-attribute?

just asking because i dont want to miss something. maybe there is something i dont understand.

thank you and keep the good work up. :)

By: L'engin

L'engin — Mon, 08 Jun 2009 08:04:27 +0000

Ok, cool!

I used the FormComponentPanel method you suggested. It took a bit (ok a lot) of fumbling with details to get it to work, but now that it’s done, works like a charm. Also, other than a few things (like have to use getParent().iterator() instead of getParent().get(int) in the RemoveButton), most things are portable as you say.

Thanks!

By: ivaynberg

ivaynberg — Sat, 06 Jun 2009 17:44:31 +0000

The only piece that is missing in 1.3.x is the IFormModelUpdateListener, so you will have to manually invoke updateModel() on the ListEditor. There are many options to do this:

Implement IFormModelUpdateListener yourself and call it from a custom form’s overridden process() method.
Put the ListEditor into a FormComponentPanel and call ListEditor.updateModel() from FCP.updateModel()
Add a HiddenField to the form and call ListEditor.updateModel() from HiddenField.updateModel()

Other then that everything else should be portable I believe.

By: L'engin

L'engin — Sat, 06 Jun 2009 08:25:02 +0000

Great article!

I was looking how to do this in 1.3.x, and it appears to be much more complicated due to final methods and coding against classes vs. interfaces.

How would you suggest one do this in older versions of Wicket?

By: Rick

Rick — Thu, 23 Apr 2009 05:15:47 +0000

Thanks for this great article. This is exactly what I was looking for. Superb.