# Website/application administration patterns \[in Rails\]

**URL:** <https://www.ruby-forum.com/t/website-application-administration-patterns-in-rails/119899>\
**Category:** Rails\
**Created:** [November 12, 2007, 2:02am UTC](https://www.ruby-forum.com/t/website-application-administration-patterns-in-rails/119899 "2007-11-12T02:02:04Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mhfs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b2d939/32.png) [@mhfs](https://www.ruby-forum.com/u/mhfs)\
**Post date:** [November 12, 2007, 2:02am UTC](https://www.ruby-forum.com/t/website-application-administration-patterns-in-rails/119899/1 "2007-11-12T02:02:04Z")

</div>

Hello!

One topic that seemed very simple in the beginning but ended up by  
being kind of complex (as more complex and bigger project came towards  
me) is the admin aspect of a web application/site.

I couldn’t find many articles/resources on “admin best practices” and  
**website/application administration patterns**. I know that the  
solution is very dependant from the problem being solved (project) but  
I would really like to know more about this subject that ended up by  
not being so trivial.

For my last Rails project, I created a static role based system where  
I defined in the controllers using before filters which kind of user  
(based on a user\_level attribute) could access each action. So, admins  
could access “POST” actions and everyone else could access “GET”  
actions.

Take Django for example - you build the application and get a  
production-ready admin interface for free. This feature is extremelly  
attractive, since I find that the most boring and time-consuming  
aspect of the application is indeed the CRUD admin interface for the  
content-creators or website administrators or whatever they may be  
called.

Also, I find that separating “front-end” controllers from “admin”  
controller (putting the admin controller into an admin namespace) to  
be a good organisational technique to focus each of them on its  
responsabilities (GETting content versus POSTing content) but many  
folks @ #rubyonrails told me that this isn’t really the way to go.

So, how would you implement an administration interface/control panel  
on a large application built in Rails? And if this application uses  
RESTful model, how should you handle it?

So, please, if you could enlighten-me on this subject, I would be  
grateful.

Thanks,

Marcelo.

---

<div class="post-metadata">

**Author:** ![mhfs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b2d939/32.png) [@mhfs](https://www.ruby-forum.com/u/mhfs)\
**Post date:** [December 21, 2007, 8:02am UTC](https://www.ruby-forum.com/t/website-application-administration-patterns-in-rails/119899/2 "2007-12-21T08:02:40Z")

</div>

Hello Marcelo,

I was wondering about the same thing myself. Initially I was going to  
build two separate applications that accessed the same database. That  
way I could completely restrict the admin application to work only at  
at one location (it would only be installed at one location). However,  
that means that I would have to keep all my models in sync and it  
seemed a more complex way of dealing with the situation. Also, I’m not  
sure if it provided all that much security.

So, I did the following

I used the admin namespace feature to separate the back-end  
administration from the front-end. Here’s a sample of my routes:

map.namespace :admin do |admin|  
admin.resources :products, has\_many =\> [:variations, :collections]  
admin.resources :collections  
end

map.resources :products, has\_many =\> [:variations, :collections]  
map.resources :collections

So this leads to ‘admin’ folders in the ‘controllers’ folder and in  
the ‘views’ folder. My ‘models’ folder was flat. I have  
a :before\_filter in the admin controllers that authorizes admins to  
access all actions. The normal controllers don’t require  
authorization, and I’ve removed any actions from them that I didn’t  
need: (i.e. one or all of: edit, update, new, create, and delete).

All of the admin controllers use the views in the ‘views/admin’  
subfolder and the normal controllers use the views in ‘views’.

Like you said, it probably is very dependent on your specific  
application, but this seemed to work well for me.

You mentioned that this method was not recommended by Rails folks on  
IRC, do you remember why?