Nearly a couple years ago Ryan Bates did a screencast titled, "Where Administration Goes". In it he makes a case for integrating administation UI within the standard templates that unprivileged users see.
- Advantages: elegant; convenient, direct access to administration; cuts down the number of templates and controllers needed.
- Disdvantages: templates are more complex and therefore harder to write and test; can’t page-cache because different visitors see different versions of page.
- Advantages: simpler templates which are easier to write and test; simpler security model; pages can be cached because they look the same for all visitors.
- Disdvantages: more templates and controllers required; no direct access to administration functions from public views; admins effectively playing in separate "ghetto" from rest of users, and so may get "out of touch" about what bugs and UI problems normal users may be experiencing.
Neither approach is a clear winner, but weighing all this up I’ve always preferred inline administration interfaces where possible, falling back to namespaced interfaces when necessary or more appropriate.
But when you add AJAX to the mix the inline approach gets a little more ugly (well, any time you add AJAX using the standard Rails helpers things are going to get a bit ugly; it’s just that doing so in the case of inline administration UI makes a complicated thing even more complicated).
We no longer have just the following (pseudo-code):
if admin? show edit button
We instead now we have a whole heap of conditionals like the following, one for each attribute we want to be editable via AJAX:
if admin? show AJAX control else show immutable (non-editable) representation
- A convenient inline UI for administrative actions
- Easier testing
The basic idea
Once we’ve proposed to do our inline admin UI this way, a couple of conclusions naturally fall out:
- The page will be truly static, will look the same for all users, and so can be cached.
- For admin users, we’ll be generating a bunch of inline AJAX controls.
- For 99% of visitors, then, we’ll expect:
- A really fast static page load.
- For 1% of visitors (the admins), we’ll expect the same, except:
Add it to each controller? Meh.
Our custom controller really needs only one method, a "show" method, which will basically do this (pseudo-code):
def show render ERB template for 'controller' and 'action' end
So let’s say we have an issues controller with a show action which we normally access from
We’ll add a quick helper that generates the appropriate
<script> tag to the
<head> in our application layout:
And why not make things a little sweeter with some syntactic sugar for use in our controllers?
All in all, a pretty nice system, I think. I’m hoping to roll it out in my next major deployment.