# FormBinding possible bug?

aUser
123 4

Hello,

i have created this fiddle and if you will test it, you'll notice that the add function doesn't show new records for each call. However, if after "a while" you remove an item, you'll see the list updated.

The problem is fixed if the add function simply adds to the list without specifing a position, hence if you change this line:

form.getEmployees().add(0, new Employee("firstName" + (++counter), "lastName" + (counter)));


into

form.getEmployees().add(new Employee("firstName" + (++counter), "lastName" + (counter)));


everything works as expected. I would like to use the method where i specify the position because in that case i don't have to use Clients.scrollIntoView(component) if the list gets quite long, hence i wanted to always add on top of the list.

Posting a notify change updates the list but i'd like to avoid that..

Do you think this is a bug or i'm missing something here?

Thank you

delete retag edit

Sort by » oldest newest most voted

MDuchemin
1901 1 5

After some extra digging, turns out the ListProxy class doesn't call the setDirty() method, which cause the automatic update if you use this overloaded add(E, int) version, but its super class does with the original add(E)

Posted a bug ticket about that :) good find! https://tracker.zkoss.org/browse/ZK-4855

I tried watching the source code of ListProxy 9.5.1 and i saw that the "remove(int index)" and "add(int index, E element) seems to work the same way which is why i'm kinda confused :O Anyway i'll wait for the fix, thank you for helping me out!

( 2021-04-09 19:05:44 +0800 )edit

sounds like you're mixing up overloaded methods ListProxy.remove(int index) vs AbstractCollectionProxy.remove(T obj) however both should work, hence the bug ZK-4855

( 2021-04-12 15:28:51 +0800 )edit

MDuchemin
1901 1 5

Hi There,

Which ZK version are you running on your side? I can reproduce the behavior with your fiddle using current latest (9.5.1.2), but I just want to make sure we are testing the same thing.

When you are making changes to the model, you can always use BindUtils.postNotifyChange(targetBean, "propertyToUpdate") to tell the binder to check for changes. In this case, you can add the following line in the add command:

  @Command
public void add(@BindingParam("form") Department form) {
form.getEmployees().add(0, new Employee("firstName" + (++counter), "lastName" + (counter)));
BindUtils.postNotifyChange(form, "employees");
}


This will let the binder know that the property "employees" of the bean "form" need to be checked for changes. Not sure why remove is picked up while add is not, still checking on that... but it's possible that it be caused by the removed employee having already been tagged by the binder, since it's already being used in the page...

Thank you, i confirm i tried with the 9.5.1.2 version and faced this issue. As i said "posting a notify change works fine.." i meant using the 'BindUtils.postNotifyChange(..)' function but it was my bad for not specifing it, i guess the first thing that comes to mid is the annotation @NotifyChange

( 2021-04-09 15:04:49 +0800 )edit

I see, thanks for the added info. I think postNofifyChange should be the primary option to trigger that update still. Is there a technical reason to not use it in this context on your side?

( 2021-04-09 15:28:24 +0800 )edit

No real technical reason so far, i'd like to avoid postNotifyChange simply because for removing it's not needed and for adding without specifying an index it's still not needed. I wanted to understand why with index positioning this stops working. It was just for "cleaner code" if you will..

( 2021-04-09 16:13:52 +0800 )edit

MDuchemin
1901 1 5

Hey There, That bug ticket is closed and has a fix implemented.

Thank you!

( 2021-05-09 18:56:56 +0800 )edit
[hide preview]