There's a lot of focus on the visual changes to the Radiant interface, but there are some functional changes that should be discussed too. I've started playing with the new AdminUI as I try to understand the changes (since I haven't had time to take part in the development). The first thing I tackled was figuring out how to rearrange the navigation items and it's not too easy to understand what's going on.
First, here's the new structure of the tabs:
NavTab #=> [NavSubItem, NavSubItem, ...]NavTab is a subclass of Array and it's accessed via admin.nav although admin.tabs will still be available (with a warning of deprecation) for some time.
I'll be posting details like this on the Radiant blog once the code is more developed.
There's debate about where Snippets ought to go: content or design? Do site editors use them, or do designer/developers use them? So that's a good place to start.
In order to do this, I had to generate an extension. Then, in my extension, I added this to the activate method:
admin.nav['content'].delete_if{ |t| t.name.to_s == 'snippets' }
admin.nav['design'] << admin.nav_item(:snippets, "Snippets", "/admin/snippets")That's complex, but it moves the "Snippets" link from the "Content" tab to the "Design" tab. It should be simpler; something like this would be nice:
admin.nav['content']['snippets'].nav_tab = admin.nav['design']but better yet, I'd rather have:
admin.nav_items['snippets'].move_to('design', :after => 'pages')It doesn't seem too valuable to implement that just to move one thing, but with the new tab/nav structure I would think that there will be a lot more customization by users/developers.
1) Does that syntax appeal to you? (Why or why not?)
To make it even simpler, it might be nice to be able to define structure in an initializer or a yaml file somewhere so that Radiant would load it's default setup, but then read your changes and rearrange the navigation accordingly. I wouldn't want to tackle that until other questions are answered, but it's an idea for the future.
Next, the recent changes only allow you to specify visibility on the main NavTab and not on the NavSubItem.
2) Do you want to be able to specify visibility on the NavSubItem?
Using the above example:
admin.nav_items['snippets'].move_to('design', :after => :pages, :visibility => :admin)Personally, I think something like this is a must. I see tabs as a way to organize links and not as much of an authorization mechanism. By that I mean that in order to hide a section to all but a specific role, you'd need to put it in it's own tab even thought it might already make sense in a place like "Content".
These recent changes are going to cause a bit of pain for developers to upgrade the numerous extensions out there, but it'll be well worth it in the long run; especially if it's easy to move things around.
Updates in Radiant have been causing some pain do to the major changes being made recently and if you're not well-versed in the core application it can be difficult to keep up. Please post your questions to the mailing list where people are generally very helpful. Although we'd all like to avoid upgrade problems, they sometimes comes from changes in Radiant or changes in Rails, and we are doing what we can to create problem free upgrade paths. But this doesn't mean that the creators or maintainers of the particular extension that you use are yet aware of your problem. Hence, the mailing list is your best option for help.
Thanks very much to John and Sean for hacking away and getting this into the master branch.
UPDATE: There's plenty of discussion going on about this on the development email list, and I've got some related changes that I hope to add to the core here http://github.com/saturnflyer/radiant/commits/tab