Critic bug on setDataSource and fetch with ListGrid

[u4ibm]

Using the latest nightly build, we've encounter a bug regarding data source changing on ListGrid.

Our scenario is as follows:
a user choose a data-source to show and a criteria to fetch with.
than we set the grid`s data-source to the chosen one, and perform a fetch with the criteria.

if the user switches the data-source more than three times, it doesn't work.
in the server logs we see that it sends the request with a different data-source id than the one chosen by the user.
In debug mode, we see that the ListGrid is set to the correct data-source and also the criteria is the right one.

There is no code to add because we simply use:
onSelection(newDS, criteria) {
grid.setDataSource(newDS)
grid.fetch(criteria)
}


Is it a known bug?

Thanks!

[Isomorphic]

No, this is definitely not a known bug. Let us know if you are able to create a standalone test case.

[u4ibm]

it is a bit hard for me to generate code here, as mentioned before, we are working on isolated network.

but basically we do nothing more than described.
we have a list of datasources and a list grid.
the user clicks a datasource and than the code above is run.
really simple, nothing more.

we don't instantiate a new grid in each selection.

hope this will be enough,
please let me know if not

[Isomorphic]

Since there are samples that demonstrate DataSource switching and they work, this is definitely not enough.

Let us know if you can reproduce the problem with a standalone test case.

[msturzen]

Hi u4ibm,

did you ever find a solution to this?

Seems like we hava a similar issue.

Any help appreciated

[u4ibm]

no, we could`t.

but refreshing the page when happens makes it work again.

[u4ibm]

anything new?

[u4ibm]

this still happens.
after N times we set the grid with a new DS and call the fetch operations it runs bad request on server.
(the criteria sent on the client is correct. the server refer to it as if it was the previous DS, with current criteria.)

thanks!

[Isomorphic]

And we still have no standalone test, nor any other user reporting a problem. So work on a standalone test case if you really believe this is a framework problem.