Rails 2.0, REST Resources, Admin and DRY

rubyonrails-talk
1

hi!

I'm doing a blog engine in rails 2. I used the restful resources approach to create my initial 'post' and 'comment' models, and it is working very nice.

However, I'm stuck with two problems, and I want to resolve them with the "Rails way" :slight_smile:

* How to disable some verbs from the restful interface?

You know, people should not be able to POST or DELETE on my blog posts. However, it doesn't seem pretty to me to go to the PostController and simply delete those methods, because the routes still appear and can be called (resulting in a beautiful error). How should I deal with this? Should I change the methods to return an error instead?

* How to make an admin area and keep DRYing?

After creating all my models, I now need an Admin area just to simple scaffold, creating posts and comment approval. But how do I do this and keep DRY? On one hand, I want to keep the admin area under the '/admin' prefix. But on the other hand, I don't know how can I keep using the created resources without repeating myself! Please, what is the "Rails way" of doing this thing?

On the ideal world, I put filters in my resources, limiting the admin operations to the admin users, and the /admin namespace somewhat maps/points to those resources instead... Please help me clarifying my mind :slight_smile:

Cheers, RĂşben

2

look here: http://www.akitaonrails.com/2007/12/12/rolling-with-rails-2-0-the-first-full-tutorial-part-2

you will get a lot of answers.

the tutorial starts here:

3

All:

I am in the same boat. "How to make an admin area and keep DRYing"...

Also, I have been looking for something that basically shows all the stuff you can and should do related to REST and routing (named routes, nested, namespaces, etc.) with Rails 2.0 and I am coming up empty.

Any insight or links to insight would be deeply appreciated.

Thanks

Resident Moron

4

Hi,

Answer to the second question inlined below:

hi!

I'm doing a blog engine in rails 2. I used the restful resources approach to create my initial 'post' and 'comment' models, and it is working very nice.

However, I'm stuck with two problems, and I want to resolve them with the "Rails way" :slight_smile:

* How to disable some verbs from the restful interface?

You know, people should not be able to POST or DELETE on my blog posts. However, it doesn't seem pretty to me to go to the PostController and simply delete those methods, because the routes still appear and can be called (resulting in a beautiful error). How should I deal with this? Should I change the methods to return an error instead?

* How to make an admin area and keep DRYing?

After creating all my models, I now need an Admin area just to simple scaffold, creating posts and comment approval. But how do I do this and keep DRY? On one hand, I want to keep the admin area under the '/ admin' prefix. But on the other hand, I don't know how can I keep using the created resources without repeating myself! Please, what is the "Rails way" of doing this thing?

On the ideal world, I put filters in my resources, limiting the admin operations to the admin users, and the /admin namespace somewhat maps/ points to those resources instead... Please help me clarifying my mind :slight_smile:

You may check the following articles:

http://www.fallenrogue.com/articles/178-Creating-a-RESTful-admin-section-in-Rails http://www.fallenrogue.com/articles/181-Creating-a-RESTful-admin-section-in-Rails-with-2-controllers

I have not yet tried them myself bu they seem to be reasonable. It would be great it you can try and provide feedback here again.

Cheers, RĂşben

HTH,

5

look here: http://www.akitaonrails.com/2007/12/12/rolling-with-rails-2-0-the-first-full-tutorial-part-2

you will get a lot of answers.

the tutorial starts here: Rolling with Rails 2.0 - The First Full Tutorial - Part 1 | AkitaOnRails.com

indeed I found! excelent tutorials! thank you!

however, my fears became real.. what Akita really do is mannually copy the resource generated files inside the admin namespace, efectivly repeating code... goodbye DRI, now I have *two* pieces of code to mantain :frowning:

anyway, I learned a lot about rails 2 with those two posts! thank you!

RĂşben

6

Hi,

Answer to the second question inlined below:

> > hi! > > I'm doing a blog engine in rails 2. I used the restful resources > approach to create my initial 'post' and 'comment' models, and it is > working very nice. > > However, I'm stuck with two problems, and I want to resolve them with > the "Rails way" :slight_smile: > > * How to disable some verbs from the restful interface? > > You know, people should not be able to POST or DELETE on my blog > posts. However, it doesn't seem pretty to me to go to the > PostController and simply delete those methods, because the routes > still appear and can be called (resulting in a beautiful error). How > should I deal with this? Should I change the methods to return an > error instead? > > * How to make an admin area and keep DRYing? > > After creating all my models, I now need an Admin area just to simple > scaffold, creating posts and comment approval. But how do I do this > and keep DRY? On one hand, I want to keep the admin area under the '/ > admin' prefix. But on the other hand, I don't know how can I keep > using the created resources without repeating myself! Please, what is > the "Rails way" of doing this thing? > > On the ideal world, I put filters in my resources, limiting the admin > operations to the admin users, and the /admin namespace somewhat maps/ > points to those resources instead... Please help me clarifying my > mind :slight_smile:

You may check the following articles:

http://www.fallenrogue.com/articles/178-Creating-a-RESTful-admin-section-in-Rails http://www.fallenrogue.com/articles/181-Creating-a-RESTful-admin-section-in-Rails-with-2-controllers

I have not yet tried them myself bu they seem to be reasonable. It would be great it you can try and provide feedback here again.

Also: http://groups.google.ca/group/rubyonrails-talk/browse_thread/thread/6b15ff7beb729cf1

7

Recently i’m working on a project when i have more than just admin and normal users, and all the work was made with single controllers for all features. I use some very usefull techniques, that i will apreciate criticisms. On this project, not just verbs is allowed/denied, but data change following the user role.

First, i use before_filters to make access control, based on roles, tools categories and functions (at now it’s just C-R-U-D). A migration categorize all actions on the system (a biggest work, walking through controllers path and identifying true actions…). ACL was made across relationship between roles, functions and tool’s categories, all category have their own function (CRUD again). The simple exclusion of verbs not work how was spoken on first email in this tread because links and other things will still pointing to actions a errors will be raised.

To fix this problems, i just write a smallest plugin, that overwrite link_to*** helpers, returning “” if the user has no access to the specific functionality.

To test this access restrictions i add useful methods like canCreate? or canUpdate? to user model.

The biggest problem was change all data on the system based on the roles, because the logic behind the scenes was very deeply: some roles has hierarchically restrictions, other roles has no restrictions, etc…

Add to this scenario, the fact that the system need information’s filters (the user select specific parent data, and all tree of data bellow this parent data will be restricted to)!

… for this purpose i work with around_filters and with_scope… An ugly but usefull code that wraps all the application data.

I speak all this things because i think that this problem is not so restrict to anti-DRY pattern, or this isn’t about REST in self. Keep your code clean on real applications that have real roles relationships is very difficult, and sincerely i think that REST is not so useful on this case. I am not speaking against use REST (i really understand how REST can help us)… The fact is that REST or no REST, the problem was the same and restriction REST based will not help you.

P.S.: just think about edit action! This is called through GET action, but users that can’t update, should not access this action…

8

since you need different urls for different actions you might consider not to use map.resource and just register the routes to the different actions using '/admin' when needed.

named route (creates admin_post_url method)

map.admin_post '/admin/post/:id',                  :controller=>'post' , :action => 'edit',                  :conditions => { :method => :get }

normal route but with specific method (you might call it with the same admin_post_url and :method=>'put')

map.connect '/admin/post/:id',                  :controller=>'post' , :action => 'update',                  :conditions => { :method => :put }

This does not require two controllers. The authentication part you will have to figure out with some plugin. I have heard of this one:

http://weblog.techno-weenie.net/2006/8/1/restful-authentication-plugin

but have not used yet...

9

I am afraid those two links are for old version of Rails and it is not using name space mechanism available in Rails 2.0. You can use:

map.resources :posts

map.namespace(:admin) do |admin| admin.resources :posts, :has_many => :comments end

in Rails 2.0. You can create the admin/posts controller by:

script/generate controller “admin/posts” exists app/controllers/admin exists app/helpers/admin

  create  app/views/admin/posts
  create  test/functional/admin
  create  app/controllers/admin/posts_controller.rb
  create  test/functional/admin/posts_controller_test.rb
  create  app/helpers/admin/posts_helper.rb

For the public view, deleting the actions that is not allowed is a practical solution. You handle the error by using the rescue_from class method that is available in Rails 2.0.

Admin section will have its own views that allow the edit, delete and so on, where the public views will not have template for those actions.

I would not worry too much about being DRY, some wetness is ok as long as it simplifies your code.

10

What are the articles you're referring to in the above? I'm on the mailing list and don't see the links you mentioned.

11

Darryl Pierce wrote: