Loading...
Important Notice - Forums is archived

To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Product icon
TUTORIAL

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.

Table not updating after item property value change

Archie Cobbs
9 years ago Apr 27, 2012 5:04pm
Jean-François Lamy
9 years ago Apr 28, 2012 8:01pm

If the property change to your table is being done as a result of a user action (that is, in a listener, or a routine invoked from a listener), then you should see it -- vaadin should repaint.

If the property change is done some other way, and not as a result of a user action, then you need something like ICEpush, or DontPush Ozone, to ensure that the browser is informed of the change.

The behaviour you describe is consistent with the second scenario: your change to the interface is queued, and until the browser comes back to query the web server, nothing happens. The queued changes are all sent on the next interaction.

Archie Cobbs
9 years ago May 07, 2012 3:07pm
Syam Pillai
9 years ago May 07, 2012 6:40pm
Archie Cobbs
9 years ago May 07, 2012 9:26pm
Archie Cobbs
9 years ago May 07, 2012 9:57pm
Archie Cobbs
9 years ago May 07, 2012 10:08pm
Henri Sara
9 years ago May 09, 2012 10:44am
Archie Cobbs
9 years ago May 09, 2012 9:11pm
Anthony Davie
9 years ago Nov 29, 2012 8:17am
Henri Sara
9 years ago Nov 29, 2012 8:52am
Anthony Davie
9 years ago Dec 01, 2012 6:43am

Hi Henri,
Thanks for the prompt reply. I'm glad to hear the table is up for an "upgrade". However, I agree with Archie, this is less of a server "push issue" it is more a case that:

  1. User does some interaction, e.g. edit an entry in a bound object
  2. Which affects underlying bound table data
  3. Expected Result: Table updates, Actual: Nothing

I would agree with you 100% if a background thread for example, changed information. But in my use case and Archie's I believe, the user did some action that affected directly the bound data.

I can prove the assertion, by simply using the same code style as the Tutorial where the Address Book is edited in a form. I've recreated the code exactly in my application. The Form object correctly updates the underlying Java Bean.

If you put a System.out.println (...) comment the correct bean values are shown after the form edit finishes.

BUT the stubbornly remains unaffected.

The very kludgy workaround of:

table.setDataSource ( table.getDataSource() ) ;

Does work, but it is messy, may have large performance implications and is just plain unnecessary code. One of the things I really like about Vaadin is precisely that for the most part, there is little unnecessary code.

Thanks for listening to my rant :grin:
Anthony

Aydin K.
6 years ago Aug 07, 2015 7:56pm
Mahesh Yadav
4 years ago Mar 22, 2018 6:06am
Vilius Kukanauskas
4 years ago Mar 23, 2018 5:17pm
Olli Tietäväinen
4 years ago Mar 26, 2018 7:14am