beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott L'Hommedieu" <>
Subject BEEHIVE-1173 -- DataGridState persistence
Date Wed, 25 Apr 2007 20:34:00 GMT
In regards to


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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message