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: Buckblog: 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: Category: User Authorization - The Ruby Toolbox

\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,