Rails - Nov 2007 - website/application administration patterns [in Rails]

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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---