Thanks, this sounds like what I need.

On Feb 22, 7:24 pm, Jeff Lewis <jeff.bu...@gmail.com> wrote:
> To initialize some db-read var (tidbit in your example) that would
> survive and be callable for each subsequent app request, you'll want
> to do so via lazy-initialization using a before_filter (mentioned by
> bill) in application.rb.
>
> How you store such lazy-init vars between requests depends on the
> scope/use of such vars by users/requests of the app:
>
> If the var that you're setting is specific to some user alone, and
> should not be shared by all users' requests, then you could store that
> var in the user's session:
>
> # in ./app/controller/application.rb
>   ...
>   before_filter :do_lazy_init
>
>   ...
>   private
>
>   def do_lazy_init
>     session[:tidbit] = Tidbit.random if not session[:tidbit]
>     @tidbit = session[:tidbit]
>   end
>
> which all of your app controller meths and view templates could then
> use via @tidbit.
>
> Note that such session vars can survive app restarts.  So if you
> really want the var to be set at app start/restart, and/or you change
> the structure/content of tidbit in the db, you'll want to clear such
> session data first before re-starting your app.
>
> If var that you're setting really is global in scope, intended to be
> shared by all users' requests and is read-only, then you could store
> it in a global var:
>
> # in ./app/controller/application.rb
>   ...
>   before_filter :do_lazy_init
>
>   ...
>   private
>
>   def do_lazy_init
>     $global_tidbit = Tidbit.random if not $global_tidbit
>     @tidbit = $global_tidbit
>   end
>
> Beware of issues surrounding use of global vars tho, and definitely
> don't use mutable global vars, due to potential data incongruity
> issues, especially when running production environment (assuming more
> than one process-/thread-instance of your app in prod env).
>
> If you're interested in Matz's opinion on use of global vars, per
> quote in Ruby Pocket Ref (http://books.google.com/books?
> id=KZU_HUYJ5yMC&pg=PA13&dq=ruby+matz+global+variables): "They're ugly,
> so don't use them."
>
> Jeff
>
> On Feb 21, 4:29 pm,ericindc<ericmilf...@gmail.com> wrote:
>
> > I don't generally follow the "whatever works..." approach because
> > there is usually a best practice.  That said, I want to avoid the
> > global variable because having $tidbit = Tidbit.random declared in my
> > application.rb broke my migrations.  Running migrations from version 0
> > when the Tidbits database doesn't exist caused the db:migrate to fail
> > because the line of code was still being executed and the Model was
> > attempting to access a table that didn't exist.
>
> > I'll keep reading, but I'm sure there is a logical way of
> > accomplishing this that I'm just not yet seeing.  Thanks.
>
> > On Feb 21, 4:41 pm, Eric <ericgh...@gmail.com> wrote:
>
> > > So why not use that, then? Whatever works...
>
> > > Also, you might brush up on MVC and beginner's Ruby as far as "setting
> > > variables in models" 
> > > go:http://wiki.rubyonrails.org/rails/pages/UnderstandingRailsMVC
>
> > > On Feb 21, 12:45 pm,ericindc<ericmilf...@gmail.com> wrote:
>
> > > > Title pretty much explains it.  I'd like to set a variable the stores
> > > > a single Model object inside of application.rb since it will be used
> > > > on every single page.  I've tried both class and instance variables,
> > > > but to no avail.  The only thing that worked so far was using a global
> > > > ($) variable.
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com
To unsubscribe from this group, send email to 
rubyonrails-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to