I am one of the founders of Upmin, and I am leading the development of our admin framework for Rails. It is still pretty early, but I would love to get your feedback on it as we try to prioritize our development efforts.
This is great compared to the other admin frameworks I tried, but I think you should now spend some time on UI polishing (size of the fields and filters, visual hierarchy) to make it pleasant to use without any additional customization.
Thanls for the feedback. We plan to iterate on the design soon. If you have specific examples and could provide screenshots of things you don't like or aren't functional you can send them to support [at] upmin.com
Looks really cool! Just a small note that I'm having some weird font issues on Windows using Chrome. (not really obvious until you download and view the full size)
This looks awesome. Pretty much exactly what I need. Do you think this will work fast enough with databases with a large number of records? Some tables in my rails app have 1 million + records.
Did rails development for 6ish years full time, about 6 months ago I joined a startup using Django. The admin is QUITE nice, its very flexible in terms of models but as well as templates, allowing you to override specific blocks from a standard template, rather than copying a template.
This looks like the very beginning of the Django admin, something that Rails could seriously use. Admin functionality isn't meant to be user friendly, its essentially a CRUD system that mimics your schema.. something that would be quite handy in Rails. While I've always painfully just created my own admin for every project, I've used https://github.com/activeadmin/activeadmin a few times, and known others who have as well. It's great, but again not nearly as simple as Django.
Personally I would love to see a Django Admin style tool for Rails.
Of course, you do kind of get this with Rails Scaffold, but its not admin, its all user facing as its produced with the model and controller, far from ideal.
Certainly ActiveAdmin has given me a share of headaches as I built my website. That being said - it works, and I'm familiar with it(and Arbre) now. How do you plan to get established sites like mine to switch to Upmin with such a high upfront cost(namely, reconfiguring Upmin to have all the same functionality I bled for for ActiveAdmin?) Any kind of migration plan?
If you already have active admin setup with a lot of things built on it, I wouldn't suggest changing it until you needed to add new stuff, or it was falling short somewhere for you. No point wasting the dev time if it works.
I would love to talk to you more about what you have customized, and what all would need to be reconfigured to get started with upmin to learn from you if you don't mind sharing. My email is jon [at] upmin.com.
I know exactly how you feel. Arbre is neat and all but I think it's a bad idea to use yet another language for your admin stuff. I always use partials so I can work in slim. I probably wouldn't switch now but I'll definitely think about it for my next project.
Truthfully, I haven't used rails_admin a lot. I can say that it is definitely more polished since it has been around much longer, but I have never tried to customize it or add in custom code so I don't know how it does there.
Maybe someone else with more experience with rails_admin could comment?
I've used rails_admin extensively in my last two jobs, but haven't used any of the other comparable admin frameworks.
If what you want in some basic inspection of all objects with very little work, rails_admin is great. It pretty much does that, the end.
Adding a little bit of role-based access levels via CanCan is also super-simple with rails_admin. Paper trail works great for a simple audit log. Customization to the level of "using friendlier names for some attributes, organizing your data logically, and showing cleaned up pretty values" is pretty painless as well.
Where rails_admin gets a bit annoying in my mind is when you want to start adding custom actions (LOTS of cruft and boilerplate and magic for relatively simple results), or if you want to break out of the CRUD for models viewpoint at all. We're trying to use it to offer some non-technical people things like access into user history, and you end up fighting against the fundamental assumptions of the framework a lot.
(That sounds critical. I think that overall, rails_admin is great at doing what it does. We're trying to push way past the bounds of what it does, and we're running into some troubles there, but that's to be expected).
The major failing of rails_admin that I've noticed when you aren't talking about DEEP customization is that it does not handle 1:many or many:many relationships well when the number of associated documents is large. Like, we may have a model that has 500 or 5,000 child documents, and there's no easy way to paginate the list of child documents. Also, if you have a polymorphic relationship, your list of candidate child documents is just a simple HTML select, which is obviously unwieldy when the candidate list has thousands of entries.
We've had exactly this experience over the last year, trying to use Rails Admin as a cheap way to build a content management system for a moderately large site with diverse types of content where we didn't really have budget to invest in building our own CMS.
Rails Admin definitely excels at getting you running very quickly by providing a simple interface for CRUD actions around basic models. Where it falls down - aside from dealing well with relationships, as you mention, which is arguably hard to get right - is when you want to extend that basic functionality and provide a better or different experience for your users. We've had to create custom views for letting users control the layout of certain content types, including various drag-and-drop operations, and that was pretty unpleasant to achieve (one of those horrible times where you just end up hopefully copying from other people's projects because figuring out how to do it yourself from the documentation is just impossible); and we've ended up writing a lot of CoffeeScript to hack Rails Admin views to do what we wanted in various circumstances - much of this ended up very fiddly due to working with a quite weighty Bootstrap DOM.
Lastly, the custom DSL, while clever, suffers from the usual pitfalls that plague these types of DSLs - your code can become quite bloated and re-use is very difficult to achieve. We have half a dozen models that broadly have the same customisations in Rails Admin, but we mostly ended up copying swathes of code from one to another because there wasn't a good way to re-use any of it.
The documentation is also a bit hit and miss, and issues on the GitHub issue tracker are pretty much left to fester, sadly.
In summary, I'd use Rails Admin again if I wanted an interface to allow experienced users to get a quick appraisal of, or make small modifications to, the data in a project; if I were doing something involving regular users again, I can't really say I'd consider Rails Admin a good option.
Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc.
The other solutions all have downsides - you can build admin APIs into the API and have a separate app call them, but it's more work. You could make a separate rails app which calls the same DB, but then you have to keep the model code in sync.
Consider using different/manifests layouts if you're concern is client-side. If it's compiling assets I think your concern is misplaced.
> admin panels tend to use large amounts of RAM etc
I don't think this is the case, or a huge concern depending on you're environment. Further, you could separate the apps into engines, they're great for this. TaskRabbit did a write up on this: http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/
Personally however, I've normally roll out the app as one piece with active-admin, generically speaking most apps have little admin-specific logic to them, for example, it's normally something like: "Do <x> for user(s)", "Approve <x> content", the type of operations you do can easily fit under the simplistic nature of what active-admin offers. This isn't a catch all however, some applications require more of an integrative approach, in which case it's development as normal, bits of functionality injected here and there so-to-speak.
You could use a rails engine to share the same models between two rails applications. Depending on the size of the project though, you may find that the economy of sharing models is a false one - applications of sufficient size may benefit from having separate models for user and admin interactions (see also: Domain Driven Design).
There's no reason you need to host the admin panel on the same server as your API. You can even add your admin tool to your existing repository and deploy that single repo to two different servers, one of which you mount the admin engine in and the other you don't.
fwiw, we use active-admin for our Ember front-end/Rails backend app. We don't have a lot of actions that our admins can take but it's been really nice to expose some of the account details for support tickets, etc...
I am biased, but I didn't like a few things about active admin:
1. Customizing views requires that you use Arbre. Learning an entirely new tool for generating webpages when every developer is already familiar with partials, html, erb, etc seemed backwards to me.
2. I tried to design upmin-admin so it was easier to setup. Active admin requires a little bit more work (but truthfully not a ton more).
3. Adding things like actions was significantly easier in upmin-admin. You basically just say what method you want to have on an admin page and it makes it work.
That said, this is very early stage (beta at best) and active admin has been under development for a while, so active admin is definitely more polished right now. That should change over time.
Definitely +1 for for using default Rails view system. I've been fighting Arbre every step of the way every time I try to do something a little out of the ordinary.
The view handling in Active Admin has always been a huge problem for me personally. I find myself at home with most any other Rails gem, but when it comes to Active Admin I always shudder and think "now I have to remember how to do things the way Active Admin likes them." Often I'll end up burning half an hour trying to figure out how to implement functionality that would normally take 5 minutes just because I have to figure out the Active Admin way. Anything that gets back to standard Rails action/template generation (like Devise) would be a godsend in the admin area.
Re the choice of haml - you don't have to use haml. That just happens to be what I chose to use, but if you watch the videos you will see that you can create partials with erb files instead.
I intentionally used erb in the videos to try to get this point across, but perhaps I should try to make it more obvious.
Just a quick glitch-in-the-matrix report... in your video about using your own widgets, the state of the shipment was "out for delivery" or something like that. But when you added the widget and refreshed, it showed as a few states behind.
How does Upmin approach forms for relationships? With both rails_admin and Active Admin, I found complex relationships like has many through multiple, and has one with scoped collections frustratingly hard. (in fairness I know it's not easy to automate)
Right now, we don't do much more than show relationships. I think we can do much better than Active Admin or Rails Admin (and hopefully they can learn from us :D) but it won't be added in for at least a week. If you want to create the issue on GitHub I can try to keep you updated on the status of this. - https://github.com/upmin/upmin-admin-ruby/issues
Nil/Empty String - not right now. If you (or I can) create an issue we can get this supported correctly.
DataMapper - An issue exists for this, but it is not currently implemented. I'm not 100% sure the scope of supporting it, but from what little research I have done it shouldn't be a major undertaking.
I've always been at peace with Rails' lack of default opinions or framework for admin views...I kind of just thought that Admin was just a hard problem to solve anyway, so why even bother. But then again, I probably would've thought that about ORM, and yet ActiveRecord can fill in very admirably...Hope this project is successful in creating that kind of happy balance between abstraction and customization.
I love it, great job guys, one suggestion though, mixing the admin logic and customisations with the model isn't a great idea, some models are already fat models, so maybe creating separate model config files would be better, thank you.
Given its recency, is it safe to assume this works for Rails 4.2.0beta? I'm working on a new project for a client and was a little dismayed that both Rails Admin and ActiveAdmin currently have problems with 4.2.0.
I haven't tested it with 4.2.0 beta yet. I can give it a go this weekend and I will add it as an issue on github as well. If you comment on the issue or email me - jon [at] upmin.com - I can make sure to update you on this.
Yes, but you will need to add you own authentication in the routes. We are looking at other ways to add auth soon, but for now this was the simplest way to get started.
Honestly, I have no idea. All of our development efforts were geared towards Rails 3 & 4. If you have any issues and want to email us (email below) we can try to help out, but I can't really promise anything for 2.3.
I am one of the founders of Upmin, and I am leading the development of our admin framework for Rails. It is still pretty early, but I would love to get your feedback on it as we try to prioritize our development efforts.
Thanks!