Session alternatives

I have a web application that is getting larger all the time. There are
now 3 separate models where I am storing the current find parameters in
session hash and it’s beginning to seem to me that this might not be a
good idea.

Before I add another model to the mess - is there a better way? Do I
have to create some table to store the current ‘find’ criteria? It seems
as though, this would slow me down and be rather clumsy.

Any suggestions appreciated

Craig

I think the easiest way to abstract how you access session data is by
creating an accessor and setter in your /lib folder and then including
it in app/controllers/application.rb and
app/helpers/application_helper.

This way, you can adjust how you handle sessions whenever you want.

For example, if we are storing a user_id in the session
(session[:user_id]):

module SessionAccessors
def current_user
User.find_by_id(session[:user_id])
end
end

and then:

module application_helper
include SessionAccessors

On 6/23/06, Craig W. [email protected] wrote:

Craig


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Derek H.
HighGroove Studios - http://www.highgroove.com
San Mateo, CA | Atlanta, GA
Keeping it Simple.
650.276.0908

On 24-jun-2006, at 13:50, Derek H. wrote:

Before I add another model to the mess - is there a better way? Do I
have to create some table to store the current ‘find’ criteria? It
seems
as though, this would slow me down and be rather clumsy.

How many find parameters you have? I found it to be the easiest to
just pass them along in the URL.
It might be rather long and it has the advantage that the user might
be having two or three parallell browsing sessions
in a handful of windows. The basic workflow goes like this: you
override the url_for method on the controllers that have to preserve
find criteria and keep your hash of finder configuraton in there. On
the next request you reinstantiate the find based on the criteria
recieved
via the URL.

This of course depends on how good yo0u manage to compress your find
criteria into a string :slight_smile: but that’s what works for me.


Julian ‘Julik’ Tarkhanov
please send all personal mail to
me at julik.nl

On Sat, 2006-06-24 at 14:21 +0200, Julian ‘Julik’ Tarkhanov wrote:

be a
be having two or three parallell browsing sessions
in a handful of windows. The basic workflow goes like this: you
override the url_for method on the controllers that have to preserve
find criteria and keep your hash of finder configuraton in there. On
the next request you reinstantiate the find based on the criteria
recieved
via the URL.

This of course depends on how good yo0u manage to compress your find
criteria into a string :slight_smile: but that’s what works for me.


well, on one particular model, I have 20 ‘find values’ (I am using
Ezra’s ez_where - find on steroids plugin) and I can see the next model
that I am going to add will have a similarly large amount too.

The notion of passing the values as params only goes so far and while it
may work for blog applications, a deeper web application needs
persistence for a decent UI - consider that a user executes a find which
then presents a list mode. If the user edits one of the records and
saves (or cancels), the user then returns to the list and I want the
‘found’ items to persist rather than force the user to start over.
Likewise, most of the column headers in the list view mode are links to
sort the currently found items. I need persistence.

I switched to ActiveRecord based sessions.

I wonder if using cookies to store this info might be better.

Thus for a few simple models, I am passing the find information in the
parameters hash but the models that are doing the heavy lifting need
persistent values and I have perhaps 50 objects in my session and I am
wondering if I am doing overkill.

Craig

I’m a little fuzzy on what I am being offered here. I have been using
sessions and can access information from my ‘users’ based upon
session[:user_id]

My issue is that to gain persistence on ‘find values’, I am tucking them
into session variables and that has worked well, I can set them to empty
but I can’t delete them. In most cases, I want them to persist…I’ve
got areas where a user can switch to a reports model, click a link and
if permitted by roles/rights, are shipped an excel spreadsheet with
personnel rows/columns based upon the ‘find values’ in the session.

My issue is that my session hash is now upwards of 50 items and I am
fixing to add a few more and am wondering if I shouldn’t be doing this
differently.

Craig