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