title: telerik radGrid - persist client state on sort/paging/filter
body: <p>Even in this <a href="http://demos.telerik.com/aspnet-ajax/grid/examples/hierarchy/nestedviewtemplate/defaultcs.aspx" rel="nofollow noreferrer">ajax example</a>
  which I really like the look of, when ever the top level grid is sorted the &quot;state&quot; of what you were doing &quot;disappears&quot;</p>
  <p>For example,</p>
  <blockquote>
  <p>Open the first person's row (Nancy Davolio) so you can see the Sales grid</p>
  <p>Sort by Order Total in the Sales grid</p>
  <p>Sort by Birth Date in the top level grid</p>
  <p>Nancy Davoilo should now be second. Open her row.</p>
  <p>The sales grid is no longer sorted by Order Total</p>
  </blockquote>
  <p>This may seem trivial, or that i'm being picky; However:</p>
  <p>If I have some text box(or some other type of method of accepting user input) on the sales grid, I would assume that this would get destroyed when sorting the top level grid.
  I would also think that even if I had this input on the top level grid, that sorting the top level grid (or filtering if there were filters) would destroy this input.</p>
  <p>It seems that even paging destroys this.</p>
  <p>The desired behavior would be for sorting and paging not just &quot;appear&quot; to be done client side because it's using an ajax request, but to ACTUALLY be done client side. Meaning that the actual rows of the grid are literally sorted(filtered, paged, etc.) client side so that any client side changes such as adding text to a text box, adding a css class to an object, [or in a more complex example adding a reference to a javascript object to an object via Jquery: <code>$(&quot;#div1&quot;).data(&quot;object&quot;,someObject)</code> would persist after sorting, paging and filtering.</p>
  <p>Is there a way to make this happen?</p>
  <p>Am I making what i'm looking to do clear? If not i'm happy to clarify.</p>
  <p>Additional Notes: I would think the client side performance hit would be minimal to do something like this as long as there were not a very large number of rows. In fact there would be a lot less work on the server in recreating all of the records, repeated calls to the server/database and as in my example at the top the subPages would only need to be created once rather than twice.</p>