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 White <craigwhite@azapple.com>
wrote:> 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
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
--
Derek Haynes
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 Haynes wrote:> > On 6/23/06, Craig White <craigwhite@azapple.com> wrote: >> 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.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 :-) 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:> On 24-jun-2006, at 13:50, Derek Haynes wrote: > > > > > > On 6/23/06, Craig White <craigwhite@azapple.com> wrote: > >> 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. > > 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 :-) 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 On Sat, 2006-06-24 at 04:50 -0700, Derek Haynes wrote:> 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 White <craigwhite@azapple.com> wrote: > > 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 > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >