I noticed this as I sometimes have an inline call to some Javascript/jQuery inside a table cell e.g. from a cc, and I noticed that calls were being made twice.
This behaviour can easily be demonstrated by adding an alert to dataTableScrolling.xhtml in the showcase :-
<h3>Client Side Scrolling</h3>
<p:dataTable var="car" value="#{tableBean.cars}" scrollable="true" height="150">
<f:facet name="header">
Client Side Scrolling
</f:facet>
<p:column headerText="Model" footerText="Model">
<h:outputText value="#{car.model}" />
<script type="text/javascript">alert('displaying: #{component.clientId}');</script>
</p:column>
On refreshing the page, you will notice that the alerts cycle through all the rows twice. (For anyone who tries it out and suffers all the clicking, there are 50 rows so the number in the clientId cycles from 0 to 49 twice
)You can do exactly the same with the live scrolling demo and the same thing happens.
The same thing happens on an Ajax update to a scrolling table.
I'm interested to know if this is the expected/correct behaviour, what is the reason for it/whether it is necessary/can it be avoided.
Rendering the whole table twice is obviously a performance hit which we could do without.
Also, it is important to be aware of the behaviour because if like me you sometimes have inline script calls, you need to know they will be called twice for each update and therefore need to ensure that you code defensively for it.
I also came across this issue when I was getting 'glitchy' updates to tables, especially with Firefox, whereby the table would briefly display all the contents without scrollbars, and then display correctly a fraction of a second later. This would happen on an update and was particularly noticeable on a sort header click where you would expect a smooth update of the table. I tracked this issue down to the use of h:outputScript in a composite component, where I had incorrectly forgotten to use target='head' as I should have done, so a JS file was being processed/loaded inline. Adding target='head' fixed this particular issue but the double rendering certainly wasn't helping.
I'm interested in any feedback on this, and am also highlighting it to make others aware of it in case anyone else hits related issues, as it is not something you would expect to be happening.
Cheers
Steve
