Rails 2.0, REST Resources, Admin and DRY
Ruben Fonseca
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" :-)
* 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 :-)
Cheers,
Rúben
Bruno Reis
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:
http://www.akitaonrails.com/2007/12/12/rolling-with-rails-2-0-the-first-full-tutorial
rails.impaired
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
On Dec 27, 4:43 am, Bruno Reis <bruno.p.r...@gmail.com> wrote:
> look here:http://www.akitaonrails.com/2007/12/12/rolling-with-rails-2-0-the-fir...
> you will get a lot of answers.
>
Ersin Er
Answer to the second question inlined below:
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,
--
Ersin Er
Ruben Fonseca
>
> 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:
> http://www.akitaonrails.com/2007/12/12/rolling-with-rails-2-0-the-
> first-full-tutorial
>
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 :-(
anyway, I learned a lot about rails 2 with those two posts! thank you!
Rúben
Ersin Er
Also: http://groups.google.ca/group/rubyonrails-talk/browse_thread/thread/6b15ff7beb729cf1
> > Cheers,
> > Rúben
>
> HTH,
>
> --
> Ersin Er
>
--
Ersin Er
Nathan Esquenazi
http://www.fallenrogue.com/articles/178-Creating-a-RESTful-admin-section-in-Rails
This is typically how I have seen it done using a single controller and
views with conditional displays of admin stuff or with routing to admin
views if logged in, etc.
Ruben Fonseca wrote:
> On 2007/12/27, at 10:43, Bruno Reis wrote:
>
>>
> 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 :-(
>
> anyway, I learned a lot about rails 2 with those two posts! thank you!
>
> R�ben
--
Posted via http://www.ruby-forum.com/.
Everton J. Carpes
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...
Mobile: +55 53 9129.4593
MSN: mas...@gmail.com
UIN: 343716195
Jabber: everton...@jabber.org
"If art interprets our dreams, the computer executes them in the guise of programs!" - Alan J. Perlis
Bruno Reis
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...
On 27 dez, 15:43, Nathan Esquenazi <rails-mailing-l...@andreas-s.net>
wrote:
>
Bala Paranj
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.
Jose Ferreira
areas with namespaces.
I read both articles above, and I think the real deal would be to use 2
controllers, one being with 'admin' namespace.
On the views, I think the best way to keep DRY, would be to use probably
some admin layout, and reuse partials from the public views. That's
possible using the right arguments to render.
Let's say you've got a Product and User models. From within
views/admin/products/index.html.erb one could use < render :partial =>
/products/index > or something like that.
Anyway, the reason for the post is, that I was reading the Rails Guides
(rake doc:guides), and there is this interesting one about routing =>
"Rails routing from the outside in" which explains a whole lot of stuff.
And I came up with this solution (but didn't test it yet) for the unused
actions on the public controllers and views.
map.with_options(:only => [:index, :show]) do |public|
public.resources :products, :users
end
map.namespace(:admin) do |admin|
admin.resources :products, :users
end
I think this can solve the issue, by using 2 controllers.
Darryl Pierce
<rails-mai...@andreas-s.net> wrote:
>
> I'm just starting a new project and I was interested in how to use admin
> areas with namespaces.
> I read both articles above,
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.
--
Darryl L. Pierce <mcpi...@gmail.com>
Visit the Infobahn Offramp: <http://mcpierce.multiply.com>
"Bury me next to my wife. Nothing too fancy..." - Ulysses S. Grant
Jose Ferreira
It's easier to see the whole discussion with this link:
http://www.ruby-forum.com/topic/136715#769291