amitjindal wrote:
Walaa wrote:
Similar issue was discussed here:
http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12322
I think you will have to avoid The ViewState for the cacheLocation of the dataSoure control.
Dear Walaa,
our project is quite large to simply use session at all places. The problem with using session (or cache) is that as we store values in session, something needs to clear them as well. Suppose a user is working on a page and we store the values in session, then as the user navigates to other pages, the values in session are still persisting. With time and multiple users this will consume a very large memory space.
As you have mentioned in ThreadID=12322 if the grid is not returning the correct viewstate as it is a AJAX control, there must be a way to enable the regular UpdatePanel behavior for the Grid/LLBL Source.
Also I am confused as to how it is working correctly with SQL data source. Perhaps because SQL DataSource is not persisting its values to ViewState or anything like that.
sql datasource doesn't update existing objects it has read, it issues new commands. I.e. it doesn't need to keep existing objects around.
Entities which are fetched and which have to be edited ARE kept around, and this is a big difference and the reason why things go wrong with viewstate: the entities edited are stored in the viewstate, but the grid doesnt update those as the actions taken are on the client, not on the server.
Viewstate works OK as long as the grid does a postback when things change: if things change but there's no postback, what exactly is edited? -> not known.
Please understand that MS provided little information how to write a datasource control other than the simple docs they have in the MSDN. We did a lot of reverse engineering on their controls to see what should be done behind the scenes. Eventually we managed to make things work on a proper level.
With the AJAX enabled controls this changed a bit, as the get - post cycle was gone. In ASP.NET the whole page object with the controls is gone when the page is rendered. Postbacks happen in ajax land but not the way one would expect: the grid gets a call, the grid calls the datasource and that one simply does what it should do. However as you can see, when such a call comes in, there's no 'current' set of entities, as those are stored in the viewstate, but the postback from the grid directly isn't sending those.
The datasource just does what it is asked to do as a datasource is a slave control, it can't do things on its own. The problem with 'updates' is that you can only update things if the object to update is there. If that object isn't sent because it's in the viewstate and the call to the server isn't a full postback, there's no object to update for the datasourcecontrol and it gives up. How is it otherwise able to update things if these aren't there?
Alternately, DevExpress offers a ASPxHiddenField. Is there a way we can use ASPxHiddenField for persisting values with LLBL code? I can specify the hiddenfield in base/master page to make sure it is always there. I am hoping it is a AJAX control and works properly with Grid.
No that's not going to help, the entity collection edited is serialized into the page's viewstate, or stored in the session or stored in the asp.net cache if you want to. You picked the viewstate, that's not going to work as we described.
Finally, if you know of any way to disable the ASPxGridView's AJAX behavior so that it behaves and provides the correct complete ViewState?
I don't know, we're not experts on te ASPxGridView, sorry... did you ask DevExpress about this? Perhaps there's a setting where the complete viewstate of a page is send to the server on the ajax calls.
