a few "best practices" questions

My app currently is working but I'm a little OCD about conforming to
best practices so I'd like to get a few things cleared up.

1. I have quite a lot of before_filters to restrict certain parts of
the site to some users, and a lot of my controllers use very similar
authorization code. Here's an example:

AController

def auth
unless cond1 || cond 2
flash[:error] = 'no access'
redirect_to some_url
end

BController

def auth
unless cond1 || cond2 || cond3
flash[:error] = 'no access'
redirect_to another_url
end

I was thinking of making a new method inside the ApplicationController
and making it a helper method as well so it can be used in all
controllers and all views. Also, I want to know whats the best way to
use respond_with instead of redirect_to in this situation. Do I need
to worry about other formats besides HTML in these before_filters?

Regarding nested resources, is it bad to have more than 2 levels? My
deepest level is 3 and it's a bother to manage it all, but if I
separate them then I'd still have to get the IDs of their "parents"
anyways by passing them in URLs or something.

My app currently is working but I'm a little OCD about conforming to
best practices so I'd like to get a few things cleared up.

1. I have quite a lot of before_filters to restrict certain parts of
the site to some users, and a lot of my controllers use very similar
authorization code. Here's an example:

You might look into a gem like cancan or something similar to handle this for you...

Regarding nested resources, is it bad to have more than 2 levels? My
deepest level is 3 and it's a bother to manage it all, but if I
separate them then I'd still have to get the IDs of their "parents"
anyways by passing them in URLs or something.

Why can't you get the parent from the child itself?

Parent has many Children...

c = Children.find(123)
c.parent => instance of Parent

?

-philip

Thanks for the advice, I didn't know about cancan, it looks like it'll
make things a lot easier for me. As for the resources, that's the case
except when I want to create a new resource. The to-be child doesn't
have a parent yet since it doesn't exist at the moment so I'd have to
pass the parent or its ID when I want to create a new resource. But in
general is there a limit to how many levels an app should have?

Its not necessarily authoritative, but here's an article that I like
that suggests limiting to two levels max: http://weblog.jamisbuck.org/2007/2/5/nesting-resources.
Usually a given resource only needs to be nested below its parent (for
create as you mention, for index if that's important, and for the
member actions if you want the scoping for some reason), so if you
have A has_many B has_many C, then expose:

As
As/1/Bs
As/1/Bs/2
Bs/2/Cs
Bs/2/Cs/3

No need for As/1 on those last two usually unless it really is unique
in describing the resource.

Also, for authorization you can also look at
declarative_authorization; I often forget about this site, but its
pretty nifty for seeing what's hip: http://www.ruby-toolbox.com/categories/rails_authorization.html

\Peter

Thanks for the link to the nested resource thing, it was an
interesting read. So I take it that it's a good idea to define both a
nested resource and an independent one for any resource that needs to
be nested?

It seems from the rest of the etiquette on this forum I'm supposed to
tell you here to top-quote when replying ;p

Thanks for the link to the nested resource thing, it was an
interesting read. So I take it that it's a good idea to define both a
nested resource and an independent one for any resource that needs to
be nested?

It depends on the resource and how you want to access it, but I
generally do.

I didn't see it mentioned in here, but if you don't use something like
make_resourceful or inherited_resource you should consider it to DRY
up your CRUD based controllers. The reason I mention that is that if
you use those then nested or not your controller code wouldn't change
(if you don't want to use one you can always copy their design pattern
to allow the same axiom of your code). Then it becomes a question of
routes and of what you want to type for the path. I.e. do you want to
do
a_b_path(@a, @b)
That means that you'll have the nested one because you need it (for
create and index for sure) and then you can decide whether you want to
enforce it for show as well (i.e. hide the Bs/1 URL

, whether you have the un-nested route or not really is just a matter
of if you want to expose that URL, since the controller won't change
at all.

Oops, I clicked some key combination that posted prematurely. That
last incoherent part should be:

Then it becomes a question of routes and of what you want to type for
the path. I.e. do you want to do
  a_b_path(@a, @b)
or
  b_path(@b)
The second is obviously shorter, but then you need to do @b.a to get
at its parent rather than @a if that matters for your application.

\Peter

ppgengler@prevailhs.com wrote in post #976295:

It seems from the rest of the etiquette on this forum I'm supposed to
tell you here to top-quote when replying ;p

Thanks for the link to the nested resource thing, it was an
interesting read. So I take it that it's a good idea to define both a
nested resource and an independent one for any resource that needs to
be nested?

It depends on the resource and how you want to access it, but I
generally do.

...whereas I generally use shallow nested resources:

as/1/bs/new => creates B #10
bs/10/cs/new => creates C #25
cs/25

The ID is already sufficient to identify the resource; there's no reason
to extend the URL unnecessarily.

Best,