In regards to https://issues.apache.org/jira/browse/BEEHIVE-1173
I think my comment in the description of this bug regarding the ability to implement a custom DataGridConfig to accomplish this persistence was a bit optimistic. I can't determine any "hook" to get the tags to use any other Config or Codec than the default. This means that all data is retrieved from and stored in the request. So, this leaves me asking: Should this be solved with a tag based attribute to allow the user to configure the scope of the DataGridState (via Config and Codec) or should the solution be to simply expand the scope of the DataGridState by default. I think the original spirit of the scope of the DataGridState being in the request was to limit the "impact" that the DataGridState would have through the life of the application/session. That would imply that putting the state into say the session could decrease usability of the tag. I tend to agree with this as the default behavior. Also, if the state were made to be more "long lived" there might need to be a mechanism to clear the state at any time. It's possible this could be solved by simply allowing for the codec to decode from any scope. It wouldn't really matter where the config/codec etc. are persisted or if they even are. The important part would be reading the state params from a more persistent location (i.e. Session). I'll investigate this option and report back. If it doesn't seem feasible then a set of "non default" state handlers will need to be created (the custom part I mentioned in the description), used and exposed to the tag (the part missing to allow this to work at this point.). Any comments are appreciated. Scott
