Map.connect / url re-writing

Hey everyone,

I’ve got an application that manages users. It has a default layout with
a navigation bar, whose links require the current user – for example,
<% link_to ‘Contact Details’, :controller => ‘user’, :action =>
‘details’, :id => @user %>

The problem with this is that I need to define the @user variable for
every controller action. It’s really redundant. I was wondering if I
could rewrite my urls using map.connect so that I to embed a user_id in
the url. So something like www.domain.com/username/controller/action
can I use map.connect to look up the id and pass it to the controller,
or do I have to look up the id associated with :username manually in the
layout?

Thanks,
Ben

To re-phrase, I want to do the following in routes.rb:

map.connect ‘:username/:controller/:action’, …

I realize I can then access :username from params[:username], but I was
wondering if it was possible to instantiate a @user variable from
params[:username] in one place that’s accessible anywhere?

Thanks,
Ben

Ben W. wrote:

The problem with this is that I need to define the @user variable for
every controller action. It’s really redundant. I was wondering if I
could rewrite my urls using map.connect so that I to embed a user_id in
the url. So something like www.domain.com/username/controller/action
can I use map.connect to look up the id and pass it to the controller,
or do I have to look up the id associated with :username manually in the
layout?

Thanks,
Ben

Ben W. wrote:

I realize I can then access :username from params[:username], but I was
wondering if it was possible to instantiate a @user variable from
params[:username] in one place that’s accessible anywhere?

Put the following in your application controller:

before_filter :init_user

def init_user
@user = User.find_by_username(params[:username])
end

Since this is now hitting the database every request for user
information couldn’t you just store the user id in the session when the
user logs in? Then you can just reference the session when you need the
id.

Eric A. wrote:

Put the following in your application controller:

before_filter :init_user

def init_user
@user = User.find_by_username(params[:username])
end

Thank you! That’s exactly what I was looking for.

Cheers,
Ben

RJ:

Yes you could. However, you would have to make sure you refreshed the
session if the user object changed. The before_filter approach seems to
be
the appropriate method. It also depends on if you’re talking about the
same
user on each request.

del.icio.us/hoganbp => needs to find my information
del.icio.us/homer_simpson => needs to look up someone else

So it depends on the intended purpose.

Ben W. wrote:

Is a single extra query worth worrying over? (I don’t honestly know
myself.)

If you get a performance problem optimize then. Don’t worry about it
until you actually have a problem.

Eric

Brian H. wrote:

RJ:

Yes you could. However, you would have to make sure you refreshed the
session if the user object changed. The before_filter approach seems to
be
the appropriate method. It also depends on if you’re talking about the
same
user on each request.

del.icio.us/hoganbp => needs to find my information
del.icio.us/homer_simpson => needs to look up someone else

So it depends on the intended purpose.

Yeah, this isn’t supposed to be a situation where someone is logged in
– it’s for viewing a user profile, whether it’s yours or not. So I
don’t think sessions really apply.

Is a single extra query worth worrying over? (I don’t honestly know
myself.)

Cheers,
Ben

@Ben:

An extra query like that isn’t going to hurt. Databases are designed to
be
queried. As Eric says below, don’t optimize until you need to. You can
cluster your backend databases, you can use model caching, there are
lots of
options if performance becomes an issue. However, for this… it’s not
going to matter. I’d be willing to bet you that there are going to be
other
areas you’ll need to optimize first :slight_smile:

Good luck!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs