Tips for writing an admin interface in rails - ruby-on-rails

I've been following this tutorial on creating a backend administration section for a rails 3 app.
I like the way it works, but the developer is required to manually generate namespaced controllers and models for each resource they want to administer in the backend.
RailsAdmin, in contrast, does not require you to do this, instead it detects which models you have in your app, and sets up admin sections for each one, without you having to generate any extra code.
Are there any resources out there, where I can learn to make my admin section work a little bit more like RailsAdmin? (I tried reading the RailsAdmin codebase but I get lost as there's quite a lot going on).
Ideally, I'd like my admin section to detect my application's models, and magically create admin pages for each one depending on that model's attributes. I'm certainly not asking anyone to write my code here, just looking for some tips on where to go in order to find out more about this sort of metaprogramming.

Related

Rails application with multiple roles

I have a rails application with 2 roles, say admin and user. But the thing is, The admin doesn't use a backend like ActiveAdmin for example. I want both Admin and User to see the same views, but depending on the role, I restrict what they can see. I'm using Cancan, but since for example both admin and user can see the product page, I end up with many conditions inside the view and controller actions stating for example if this is an admin show that, if not then show that instead.
So I don't really think that this is the "Rails way". I end up with many repeated code, and code inside the views which doesn't really support the idea of keeping the logic away from the views.
So my question is, What's the best way to implement such a scenario with many roles but the same views.
Thank you.
I'm thinking of two options currently, but I don't like either. One is to redirect the admin to another view, but this way most of the view is the same hence it's not DRY at all.
Option 2 is to use the exact same view, but add many conditions in the view, so I end up with a huge complex view with code. I'm trying to find a way that keeps things DRY yet simple, and keeps the views code free.
You can have the admin module under seperate namespace and users as the default namespace. You can extract the common code under partials and use the same in both admin and user module.
This way you can separate the code for user and admin, and if sometime in future if you decide to go for a different views for admin and user. It won;t be much of a task.
Have controllers as
app/controllers/admin/articles ------ for admin users
app/controllers/articles ---- for normal users
and
views
app/views/admin/articles
app/views/articles
app/views/shared
There are different possible approaches. A variation of the 'decorator' pattern would come to mind as described here
It's some time I last read it, but I think the basic idea is to put the logic in the model or helpers. As soon as a user logs in and you can see if he is an admin or normal user you have methods that return the necessary html or text.
A more simple approach would be to just have two partials for everything. Either as Ross says in a separate admin namespace or even simpler (but more work if you later need to change that) just like _user_view_something.html.erb and _admin_view_something.html.erb.
Somewhat similar thoughts go into the DCI pattern. This Blog gives some nice overview how this could play into Rails. The article is more about permissions, but again the basic idea is to supplement the user object with the necessary functions.
So you have the basic "do_something" method which renders something or places some information in the view and replace it with the one that fits to the role the actual user has.

Rails Active_Admin VS. my own backend

I've been thinking of writing my own backend, because I feel active_admin might not support all the requirements.
I wanted to ask if Active_Admin supports any of these just to be sure:
I have a has_and_belongs_to_many relationship between my ad model
and tag model. In the new ad page I would like to have the form for
the ads, as well as all available tags so the admin can choose which
tags to associate with the ad. I was able to do that normally in my
application, but can I do that with active_admin?
Can I add custom buttons.. Like one to convert to PDF for example,
or one to send an e-mail..
Could I add some sort of before_filter, so the admin can only view a
model, but not edit or delete it for example?
Thank you.
All of those things can be done via Active Admin, but as it was pointed out, it can be quite a nightmare actually implementing certain things depending on the amount of flexibility you need it to have. For that exact reason, I decided to start rolling my own administration panels.
I have tried an implemented almost all robust gems for admin panels. I have also sweated over several hand-made ones.
Active-Admin is very usability centred, but it is not configuration centred.
As you rightly aniticipated, some of the more complex modifications can be tedious.
In my experience, rails_admin is the best middle ground I could find.
Take a look at it, it is highly functional, completely modular (made as a Rails 3 Engine) and simpler to modify.
If you can live without some details when customizing this is definitely the way to go. However, if you need to have everything just right, then there is not substitute for hand-made.

Rails Design Question: How should I structure my controllers for multiple privilege levels?

I am writing a site with multiple levels of privileges. There are basically 3 kinds of users in my system. They are Admin, Business, and Consumers (normal users). Let's just say that I am building an advertising site.
So I have a model "Campaign" which has a RESTful API that comes with rails scaffold. Businesses can create campaigns, users can only see which campaigns they want to join, and admins can do everything.
Now, I know how to apply before_filter and check rigorously for the type of users that can access a particular view.
However, each level of privilege has its own unique views.
Businesses can see the insights and analytics of their campaigns. (let's call this campaigns/analytics)
Consumers can see all the campaigns that they have participated in. (let's call this campaigns/your)
And admins have special views where they can monitor the site's activity. (let's call this campaigns/monitor_businesses).
Right now, my CampaignController has the usual RESTful views + analytics + your + monitor_businesses. Of course, I have multiple data models (not just campaigns) and this makes my RESTful controllers for those data models to be really messy.
What should I do? I am seriously considering starting a ConsumerController and then a BusinessController and put all associated views in these controllers. I don't know if this violates "RESTful" principles but I want to know what better patterns exists to deal with my problem.
I am open to all kinds of suggestions.
Why dont you try the CanCan gem for role management?
You can install as you would any gem using bundler.
It is easy to set up and keeps you from creating the same boilerplate code that you normally would by creating extra controllers or actions.
To get you started I suggest that you visit the documentation on the main page. There is more information about defining what a user can do here and you can see how to check for abilities here.
You also need to add one line to controllers you want to enforce permissions on which you can read about here.
If the standard documentation isnt enough to get you started why don't you take a look at Railscast 192. It shows you how to get up and running with CanCan and it is a great source because Ryan Bates is the creator of the screencast as well as the creator of CanCan. If the video moves too fast for you there is a text version here.
y dont you try the cancan gem for role management http://rubygems.org/gems/cancan
or do gem install cancan I hope this helps.

Symfony admin generator: To be or not to be?

on the last projects i've started, I wondered if I should use the admin generator or not. My usual choice is to not use it, as some developers suggested to me, "unless it's for quick backend prototyping and submission to client", they said. Currently i'm starting a project and i'm in the situation that the client need the backend very fast to start loading lots of data, and i'm doubting about using the admin generator or not. I would use it if needed simple form fields. But one of my models must have multiple images, and maybe I need a more complex view that allow the client to load N images, so the admin generator maybe it's not the best choice, but it seems fast, it seems to save time and that's what I need now, time saving!
The project is very simple, it's just a Product model with multiple images and multiple sizes and belongs to a simple category.
What do you think? What would be the best option for this? And where do you think that makes sense to use the admin generator or the regular module generator?
Thanks in advance!
Regards.
I use the admin generator as much as possible. It is really designed to be great for the "backend" of your website-- the administrative screens which authors and editors will use to maintain the app. Any module that needs to be user-editable and is simple cries out for the admin generator.
Recently I have been starting everything with the admin generator so that there's a working prototype to build data with. Then I select certain modules or views that need more magic sauce, and build them out with more customization.
Remember, you can add views and forms to an admin generator module. On my last project I used the admin generator for the "edit" action of my main object but added "show" methods similar to a non-admin-generator form-- adding an executeShow() action and showSuccess template.
The other thing to keep in mind is that the admin generator is only a generator. It writes a bunch of code for you in cache/frontend/env/modules, but you can override any of it by building the equivalent code in apps/frontend/modules/. If you find one part of it that you can't configure with generator.yml, you can copy the file out of the cache into your module dir and hack away. I prefer to take the "out of the box" admin generator as far as possible before customizing it, though.
i've been working with symfony for quite some time now and i've been using the admin generator for simply and complex situations. It's true that it saves time when developing CRUD modules, but i dont think that is not advisable for complex cases.
I think you should use it and also learn the power of customization the generator gives you. If you have complex Forms, leave that for form classes to manage and as you said, if your forms a quite more complex to render, well you should only take care of the rendering of that only segment of the view.
But, if you decide to make if without it, you should start thinking about creating all the view from scrap, that in my case takes quite time ( i'm not so versatile wiht css).
But this is only my opinion, hope this helps you make a more rational choice!

Order / Priority of development in Symfony

So I've decided after much debate and research to use symfony on my next project. To sum the project up, it is an LMS (Yes, I know there are pre-built ones such as moodle but they do not have what my particular company requires). There are many modules and issues to take into consideration. My question is in what order should one start with Symfony?
Note, the database is already made and populated with data.
The Doctrine ORM?
User Authentication?
Creating the Core modules? (Courses, Enrollment, Grades)
Page security (i.e. installing the rules for who can access what page)?
Checking out the Jobeet tutorial is good advice.
If the database is already built, I would probably do something like this:
Ensure you have a plan of what "objects" and functionality the site is to have (eg. list of courses, course detail page, course search, etc). You should be able to visualise the site and have some design mockups ready. It would also help to know whether it's going to be multi-language or not.
Generate Doctrine models & form classes on the back of your db
Create home page placeholder (probably a module) and a logged-in home page placeholder (probably a module) + basic layouts for further tweaking later.
Create signup & authentication processes (so you have the core functionality of adding users, signing them in and signing them out). Use sfDoctrineGuardPlugin.
Now, start creating core modules one by one according to your plan. As you progress, you'll notice what bits make sense as partials/components and where an additional module might make sense. Add new routing rules as you go along.
Finally, add any little bits, cleanup your template HTML/CSS, JS files, etc
... this way you have a work-in-progress site that you can play around with as you go along.
If I were you, I would try to follow this tutorial : http://www.symfony-project.org/jobeet/1_4/Doctrine/en/ You can certainly match each step of the tutorial with a feature your website has.

Resources