Enrique Medina wrote:
Fantastic. NULL tells JSF just to stay in the same page, so it should
work as you have tested. But the problem still remains when navigating
to another page, doesn't it?
Yes that is a huge problem, but the problem is bigger than it seems, it
is basically the old scope problem, which means that you basically loose
all the values unless you traverse it, because we do not have a scope
system between request and session, and add to that some weirdness in
the behavior between the datatable and the scroller and you run into
this mess.
Shale can solve that to some degree, but I rather doubt it will solve it
for the datatable, the problem is sort of much more fundamental.
I will try to explain what happens and why the values are lost between
faces-config navigations:
What happens in a null:
The values are cleard the form values are refilled, the parameters are
passed via a submit...
The datatable is generated
the scroller is generated does an encodebegin with all the needed
calculations passes it to the datatable for further reference,
the datatable is rendered
and then the scroller does its rendering.
What happens if you dont do the refresh but a faces-config based traversal:
The steps until the encodebegin are identical, but then the problem
arises in between encodebegin and renderchildren, the datamodel is lost
along the way and a new one is generated, which is not the same as the
rendered one, thus passing the values, altering the states, etc... does
not have any effect on the rendering and the table->scroller subsystem
resets to the first page.
I tried to fix that, but I ran against my limited knowledge of JSF.
Probably to fix that a new datatable and scroller maybe a combined
component has to be implemented.
Trying to fix it from outside with a bunch of listeners which hook into
the component definitely wont help neither does altering the scroller
rendering code, because the problem is nested much much deeper.
