On Saturday, May 13, 2006, at 8:50 AM, Brett W. wrote:
something and tag on the extra options there.
Rails mailing list
I did something like this a while back… the basic approach I ended up
using was to create a view_settings table and then I stored the YAML of
the params hash with the page_uri and the user_id.
The table looked like this, I think
You can then use a before_filter in your controller to recover the
params hash, overwrite any params with values that were actually passed
with the request, and then render the page.
You can use an after_filter to update or create the appropriate entry
for the view. I would limit this before_filter to :only=>:list or other
actions that actually have settings to save, otherwise the table will
get huge and will end up with a lot of dead view_settings for deleted
records and such.
The advantgage of this method is that it transparently remembers the
state that each user left the page in last time they were there, and
this setting persists across sessions.
You could hack this approach a bit and have it remember settings for two
separate views to the same page. You would only need to find a
consistent way to make the ‘uri’ key different.
You could generate a unique window id (perhaps based on the current
time) and pass it in the params if one doesn’t already exist. This
could be added to the URI to make it a unique entry.
You would need some method to clean out old view_settings that don’t
apply anymore. If you use the unique window approach, you also won’t be
able to persist settings without a bit more work.