I'm having issues with filtering datatables that were not rendered in the initial page load but have been loaded later. This is a very basic example to show what I mean. We are also integrating with spring webflow so the problem could be there but I figured I would post it here to see if you guys have any idea what could be wrong.

PF version: 3.0.RC2 (As far as I can tell it has been present in all 3.X versions but NOT in 2.2.X)Spring version: 3.0.4.RELEASEJSF version: 2.0.4Webflow version: 2.2.1.RELEASEEDIT: Server is for example tomcat 7.0.12, but I have tried with others also without success.

If we put breakpoints here, we can see that when we load the table with ajax, enableFiltering is called and the subsequent isFilteringEnabled calls return true as expected. However, in the next request that is sent from the 'onkeyup' filtering event, isFilteringEnabled returns false as it can't find any 'filtering' property in the state helper. In the case where the table is rendered with the intial page request, the filtering request correctly returns true and the table is filtered. The likely conclusion from this is that the problem is in the webflow persistence, but I'm puzzled by the fact that it was working fine in 2.2.1.

If you need any additional information about our configuration don't hesitate to ask.

I stopped using rendered="..." property of components, because I didn't like the resulting conditional/unexpected behavior. Since you have success when the dataTable "is rendered" on the page, can you add a style="#{bean.renderDataTable}" which will hide the rendering of the dataTable when necessary?

@ViewScoped: a bean in this scope lives as long as you're interacting with the same JSF view in the browser window/tab. It get created upon a HTTP request and get destroyed once you postback to a different view. It doesn't immediately get destroyed when you leave/close the view by a GET Request, but it is not accessible the usual way anymore. JSF stores the bean in the UIViewRoot#getViewMap() with the managed bean name as key, which is in turn stored in the session. You need to return null or void from action (listener) methods to keep the bean alive. Use this scope for more complex forms which use ajax, data tables and/or several rendered/disabled attributes whose state needs to be retained in the subsequent requests within the same browser window/tab (view).

I stopped using rendered="..." property of components, because I didn't like the resulting conditional/unexpected behavior. Since you have success when the dataTable "is rendered" on the page, can you add a style="#{bean.renderDataTable}" which will hide the rendering of the dataTable when necessary?

By the way, I didn't see you reference a scope in your bean. rendered property is mentioned in the quote/blog below.

I did consider using display:none instead, but as the tables can take 5-10 seconds to load it would be inconvenient to load that many of them at once. In that case it would be better to stop using ajax to load the tables and just have the entire page refresh.

The bean is located in the Flow Scope as you can see in the top code example. I believe this scope is webflow specific and not used in pure jsf.

I did consider using display:none instead, but as the tables can take 5-10 seconds to load it would be inconvenient to load that many of them at once. In that case it would be better to stop using ajax to load the tables and just have the entire page refresh.

1. To resolve the performance issue (5-10 seconds to load), have you tried LazyDataModel yet? Click here for some code that I provided.

2. So what did you decide to do? Are you just going with the full-page refresh instead of AJAX or PPR (Partial page refresh)?

1. We have considered LazyDataModel which could be useful with or without filtering (10 seconds is pretty bad even if it's just one table), but the backend does not expose a good way to select rows with an offset. Still, thanks for the code example, might be able to turn it into something.

2. We haven't decided on a final solution. The next release deadline is several months away so I'm now working on some other stuff while trying to get input here. The issue isn't blocking as filtering is merely a convenience feature, and 95%+ of the time the user will get the relevant table loaded when he first enters (in that case the filtering works fine).

1. We have considered LazyDataModel which could be useful with or without filtering (10 seconds is pretty bad even if it's just one table), but the backend does not expose a good way to select rows with an offset. Still, thanks for the code example, might be able to turn it into something.

I think there is a way to select rows with an offset. Please click here, and see how this PrimeFaces developer was selecting 1st row onPage event (p:dataTable event="page"). it's not the final post in that conversation, but below is the code excerpt from the URL I just provided above; bean and xhtml is provided/discussed too in that post.

I ended up just changing the ajax event from 'update=":tableForm"' to 'oncomplete="window.location.reload()"'. Kind of an ugly solution, might try to implement a completely new table handler with lazy filtering, sorting and paging for a later release, but ended up being just too much work for this one.