Show HN: Upmin – An Admin Framework for Ruby on Rails
upmin.com
upmin.com
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!
https://www.dropbox.com/s/fokwygisejzzk4m/Screenshot%202014-...
Thanks!
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.
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.
If you have any questions there is almost always someone on our HipChat support room - http://www.hipchat.com/gvREostp6
Maybe someone else with more experience with rails_admin could comment?
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.
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.
It was a great asset early in the project, but we have likely lost time over the course of the build simply trying to work around Rails Admin.
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.
Anybody found a good solution to this?
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.
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.
stuff like arbre, too much dynamism/magic, not so rails way, custom css...
at first look upmin seems on the right way (imho), but i personally don't like the haml choice.
I intentionally used erb in the videos to try to get this point across, but perhaps I should try to make it more obvious.
- I need my fields to be nillable. Does upmin differentiate nil and empty string?
- How difficult is it to add support for DataMapper?
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.
Our email address is support [at] upmin.com